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Dis*Doc Professional 7 


New Dis # Doc Professional is your dual-mode disas¬ 
sembler to any DOS source code. It works in batch 
and interactive modes simultaneously, allowing you 
to generate the core information of even the most 
complex programs fast... and modify them even 
faster. Most programs will come apart in just two 
minutes. Imagine what you can do with a tool this 
powerful! Dis’Doc sifts through programs eighteen 
times for guaranteed accuracy. When code gets 
mixed up with data, our toolbox comes to the rescue 
with smart search and easy edit utilities. 

Warning: Dis*Doc Professional may change the way 
you work forever. 

Programmers who used to shy away from fixing 
outmoded programs with no source code are going 
to discover a valuable new talent: the ability to 
modify and revise codes that would cost way too 
much to start over (it's a programming manager's 
dream). Save your employer nuge new-program¬ 
ming fees and enhance your marketability. Dis'Doc 
is so easy to learn, you'll be a high-dollar hero in no 
time! 

Dis'Doc Professional is an amazing new teaching 
tool. Learn how programs work...take them apart 
and see the writing techniques that top pros use. Use 
it to assist in debugging. Hunt down viruses and 
write killers. Dis’Doc can save you years of frustra¬ 
tion, and it only costs $249.95. 


"A simple must in any serious programmer's toolbox 
We used it to compress BIOS' for BlueMAX." 

-Bob Smith, President, Qualitas, Inc 


COMPARE FOR YOURSELF! 
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5 sec. 

' Based on a 9040 byte EXE file. 2 Does not automatically separate code from data. 


To order your Dis*Doc Professional™ disassembler 
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Newington, CT 06111-1320 USA 

MasterCard & Visa Shipped Immediately Via UPS Blue inside US. 














































C CODE FOR THE PC 

source code, of course 

Image Compression Library (patented ”VARI” technology, transmit full screen in 15 seconds, includes JPEG, license required).$950 

Virtual Memory Objects (btrees, lists, arrays, and other multiple memory classes in heap, EMM, and swap file; no royalties).$750 

Embedded DOS (full-features, real-time, multitasking, 3.31-compatible DOS for embedded system and self-bootable installations).$375 

Spell Time (spelling checker for incorporation into text products; no royalty; large dictionary; small and fast).$300 

NE W! Imaging Objects (C+ + object library for imaging, PCX & TIFF, convolutions, print with dither, diffusion & halftones).$290 

ZIP Image Processor & Victor Image Library Version 2.0 (brightness, contrast, merge images, TIFF/GIF/PCX/bin, HP ScanJet support) . . $290 

Turbo If X (Release 3.0; HP, PS, dot drivers; CM fonts; LaT^C; MetaFont).$250 

Rogue Wave tools.h+-f- or math.h++ Class Library (extensive docs)...each $240 

Meijin+ + (C+ + class library for modeling & simulation; queues, statistical tools, fourier transforms, differential equations; no royalties) . . $220 

NE W! PxSQL (SQL for Borland’s Paradox Engine; ANSI X3.135-1989 SQL-DML standard; network server not required).$180 

NEW! Embedded DOS Utility SDK (C source for standard DOS utilities— FDISK, FORMAT and COMMAND.COM).$170 

C-pslib (PostScript generation library for C programs; includes complete graphics, font, rotation & paragraph support.$170 

WKS Ltbrary Version 2.01 (C program interface to Lotus 1-2-3, dBase, Supercalc 4, Quatro, & Clipper) .$155 

NE W! Empty Shell (run a program in an empty DOS shell; written in assembler for speed and small size; C call interface).$150 

Minix Operating System (Version 1.5; Unix-like operating system, includes manual; specify 5.25” or 3.5” diskettes).each $150 

Updated! Delorie GCC for MS-DOS (Version 1.05; includes C++, assembler, DOS extender, 387 emulation; complete source code and makefiles) . . $150 

Updated! Heap Expander (Version 3.0, virtual memory manager using expanded memory, extended memory and disk; XMS, VCPI, LIM).$135 

CBTree (B-f tree ISAM driver, multiple variable-length keys) .$135 

TE Editor Developer’s Kit (full screen editor, undo command, multiple windows; with word processing: $195; Windows 3.0: $200).$130 

NEW! XMEM (extended and expanded memory manager; written in assembler with C call interface; swaps to disk; small and fast).$130 

Booter Toolkit (floppy disk bootstrap routines, DOS file system, light-weight multitasking, windows, fast memory management) .$120 

WinMem (unlimited global memory handles for Windows 3.0,4-byte overheadper block rather than 20, virtual memory for 286).$110 

CSIM (discrete event simulator library; clocks, chains, future events, multiple servers, queues, reports).$100 

Updated! PC/IP (CMU/MIT TCP/IP for PCs; Clarkson drivers, NFS server, Bdale mailer, PCRoute/PCBridge, NDIS/ODI drivers, Beholder, more) . . $100 

Heapman (application memory management for Windows 3.0; 64K bytes of heap space; includes memory browser/debugger) .$100 

EZTTieve (Novell Btrieve access with data dictionary and data manager; no royalties).$100 

NEW! EZBase (C interface to dBase files; create, read, write & update .DBF and .DBT, includes index support).$100 

CDB for DOS & Unfit (database toolkit; ISAM, DDL, relational & network, space reuse, concurrent access; fast, no royalty).$95 

Kier FinanceLib (interest, conversions, annuities, depreciation, cash flow, bonds, etc.).$95 

PowerSTOR (Version 1.2; extended heap space on extended memory, expanded memory, and/or hard disk).$95 

Script Interpreter (a command script interpreter for DOS-based systems; C-like script language; lots of features).$90 

Visions 1.20 (text window user interface management system; includes mouse support and background processing).$80 

VMEM (virtual memory manager by Blake McBride, Version 3.6, LRU pager, dynamic swap file, image save/restore).$80 

cbase (C database library, sequential & b+-tree random access, buffered block I/O, file-level locking).$75 

TreeDraw (PostScript display of labeled hierarchical trees; DOS & Windows screen display included; Moen algorithm).$75 

FlexList (doubly-linked lists of arbitrary data with multiple access methods; specify C or C++).each $65 

Foundations-1 C++ Class Library (ASCII record I/O, bit arrays, exception handling, B-tree, persistent objects).$60 

NEW! LDB (Loose Data Binder; persistent data objects for C++; handles pointers between objects) .$60 

Kier DateLib (all kinds of date manipulation; translation, validation, formatting, & arithmetic).$60 

NE W! MEM.WING (global memory manager for Windows, supports standard C memory allocation calls to "wing” your old C code into Windows) . $55 

Coder’s Prolog (Version 3.0; inference engine for use with C programs).$60 

FinanC (large collection of financial function including bond, inventory, stock portfolio, & cash flow).$55 

Mini IDL (interface generator for complex data; single inheritance, translator & table generator tools, ASCII external form only)).$50 

CALC (ASCII algebraic expression evaluator, unlimited parenthesis nesting, symbols, 32 built-in functions, easily extended).$50 

Backup & Restore Utility by Blake McBride (multiple volumes, file compression & encryption).$50 

Floppy TAR (TAR backup and restore on MS-DOS devices; direct access to non-standard devices) .$50 

SuperGrep (exceptionally fast, revolutionary text searching algorithm; also searches sub-directories).$50 

OBJASM (convert .obi files to .asm files; output is MASM compatible) .$50 

CLIPS Version 5.0 (rule-based expert system generator; advanced manuals available at additional cost).$50 

NIH Class Library & Book (basic C++ classes & Data Abstraction and Object-Oriented Programmingm C+ + in softback by Keith Gorlen) . $50 

Editor Pack (15 public domain editors; including microEmacs 3.11, Stevie, Elvis, Moke, mg2a, DTE, Jove, & Origami).$50 

NEW! MicroC C Compiler (retargetable C compiler wrth optimizer, libraries, and utilities; lots of docs, very portable, tables for 5 cpu’s).$45 

NEW! TOUR (beautiful traveling salesman problem solver, finds minimum length paths quickly, includes graphics & plotting programs) .$40 

NE W! Cint (C interpreter).$40 

DES Encryption & Decryption (2500 bits/second on 4.77 MHz PC for on-the-fly encryption at 2400 baud; domestic distribution only) .... $40 

RXC & EGREP Version 2.0 (Regular Expression Compiler and Pattern Matching; finite state machine from regular expression).$35 

Updated! Database Pack (9 databases -simple to complex: isam, bplus, AVL, SDB, ID, gdbm, Requiem, Ingres89, Postgres).$35 

Bison & BYACC (YACC workalike parser generators; documentation; no restrictions on use of BYACC output).$35 

Object-Oriented Programming in C+ + (code from the book by Naba Barkakati).$30 

Spell Pack (6 spelling programs, a hyphenator, 2 utility packs and a 60K word list: Ispell, Microsp, Sp, Cspella, Spell, Dawg, Soundex) .... $30 

REGX Plus (Version 2.0, search and replace string manipulation routines based on regular expressions).$30 

GNU Awk & Diff for PC (both programs in one package).$30 

Big Number Pack (7 arbitrary precision arithmetrc packages in C, one in Fortran but free Fortran-to-C converter is included) .$30 

Crunch Pack (30 file compression & expansion programs; now includes portable ZIP).$30 

Updated! UUPC Pack (UUCP for the PC; UUPC Version 1.11k by Wonderworks and smail/PC Version 2.5 by Stephen C. Trier).$25 

PERL for MS-DOS (C, sed, awk, and shell all rolled into one language; includes hardcopy docs).$25 

Updated! Tel Version 6.1 (Tool Command Language; add shell programming capability to any command fine; elegant command line language) .... $25 

FLEX (fast lexical analyzer generator; new, improved LEX; BSD Version 23.6 with docs) .$25 

Livermore Loops in C (the famous Fortran benchmark transliterated to C; includes technical report as PostScript file) .$20 

XLISP 2.1 (includes Almy improvements).$20 

GNU RCS (FSFs version of the Revision Control System; like Unix’s SCCS only better; keeps track of software development).$20 

Gperf Version 2.5 (GNU’s perfect hash table generator; requires DJ gcc; includes executable; specify C or C+ +) .each $20 

SDBM (fast, disk-based hash table manager for really large hash tables; clone of Unix ndbm) .$20 

Data 

Moby Thesaurus (25K root words, 1.2M synonyms; requires signed license agreement).$350 

Moby Part-of-Speech (200,000 words and phrases described by prioritized part(s)-of-speech).$120 

Moby Words (500,000 words & phrases, 9,000 stars, 15,000 names).$80 

Moby Shakespeare (plays, sonnets, etc. ... every last word).$60 

Dictionary Word List (234,932 words in alphabetical order).$60 

Roget’s 1911 Thesaurus .$40 

U. S. Cities (names & longitude/latitude of 32,000 U.S. cities and 6,000 state boundary points).$35 

The World Digitized (100,000 longitude/latitude of world country .boundaries) .$30 

Lots 'O Words (160,086 German, 178,430 Dutch, 61,843 Norwegian, 60,453 Italian, 138,257 French, 53,142 English) .$30 

CIA World Bank II Database (also known as the "small” CIA world map; coastlines, rivers, lakes, political boundaries).$25 

Updated! Text Pack (1990 CIA World Fact Book, Hacker’s Jargon File, Acronym List, Koran, Mormon scriptures).$25 

Dan Klein’s Dictionaries (53,091 words and phrases in 25 dictionaries).$20 


11100 Leafwood Lane much more ... ask for catalog FAX: (512) 258-1342 

Austin, Texas 78750-3587 USA E-mail: info@acw.com 

Free surface shipping for cash in advance For delivery in Texas add 7% MasterCard/VISA 
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There’s A New Meaning To 
Painting By Numbers 

...with the Windows Control Palette™ for C, C++, Turbo Pascal and Visual Basic. 


Why settle for standard Windows con¬ 
trols that make your application look and 
operate like just another interface? With 
Windows Control Palette™ you can 
produce Windows interfaces that distin¬ 
guish your applications from others. 
And, you can do it in no time at all. 

Packaged as a dynamic link library 
(DLL), Windows Control Palette is a set 
of routines that can be used with most 
programming environments that work 
with DLLs. And, it’s easy, fast and 
flexible. 


□ Request 106 on Reader Service Card □ 


Offering a choice of colors and styles for 
creating custom controls, tool bars and 
dialog boxes, the Windows Control 
Palette gives you options that the masters 
could only dream about. 

Everything is under Control... 

The Windows Control Palette reference 
manual describes in detail how to use the 
custom controls and how to modify them. 
A DLL of bitmaps makes it easy to cus¬ 
tomize the controls to your preference. 
Examples are provided for C, C++, Turbo 
Pascal, Visual Basic, Smalltalk/V and 
Actor 4.0. All source code is included! 



BLAISE COMPUTING INC. 


For applications suitable for framing... 

Windows Control Palette requires Win¬ 
dows 3.0 or later and is just $ 169. If in the 
first 60 days you feel Windows Control 
Palette has not helped you to create a 
masterpiece, we’ll refund your money. 
No questions asked. 

Call our order department toll free at 
(800) 333-8087! 

Or, to order by fax, (510) 540-1938. 

TMs are property of their respective holders. 


819 Bancroft Way Berkeley. California 94710 (510) 540-5441 























































Windows/POS 

□ DEVELOPER'S JOURNAL 


EDITORIAL 

Senior Editor/Publisher Robert Ward 
Editor Ron Burk 

Managing Editor Martha Masinton 
Associate Editor Diane Thomas 
Contributing Editors Paul Bonneau 

William Roetzheim 
Dan Saks 
Leor Zolman 
Victor R. Volkman 


ADVERTISING AND MARKETING 

Marketing Director Jeff Dickey-Chasins 

Acct. Manager, East Ed Day 

Acct. Manager, Midwest Donna Stucky Ward 

Acct. Manager, West Edwin Rothrock 

Advertising Services Paula Cobb 

Direct Marketing Bill Uhler 

PRODUCTION 

Art Director Susan Schuette Buchanan 

Graphic Artist Twyla Watson Bogaard 

Typographer Ann Brocker 

Production Coordinator Liza Behymer 


CIRCULATION 

Customer Service Chrissy Trybom 

Order Fulfillment Jodi Leonard 


STAFF 

Business Manager Cherilyn Merrill 

Technical Kenji Hino 

Leor Zolman 


Subscriptions: Annual renewable subscriptions 
to Windows/DOS Developer’s Journal are $29 US, $38 
Canada and Mexico, $48 overseas. Payments must be 
made in US dollars. Make checks payable to Win¬ 
dows/DOS Developer’s Journal. 

Entire contents Copyright © 1992 R&D Publica¬ 
tions, Inc. No portion of this publication may be 
reproduced, stored, or transmitted in any form, includ¬ 
ing computer retrieval, without written permission 
from the publisher. All Rights Reserved. Printed in the 
United States of America. Quantity reprints of 
selected articles may be ordered. By-lined articles ex¬ 
press the opinion of the author and are not necessarily 
the opinion of the publisher. 

Advertising: For rate cards or other information 
on placing advertising in Windows/DOS Developer’s 
Journal, contact the advertising department at (913) 
841-1631, or write Windows/DOS Developer’s Journal, 
1601 W. 23rd St., Suite 200, P.O. Box 3127, Lawrence, 
KS 66046-0127. 

Customer Service: For subscription orders and 
address changes, contact Windows/DOS Developer’s 
Journal, 1601 W. 23rd St., Suite 200, P.O. Box 3127, 
Lawrence, KS 66046-0127. Telephone (913) 841-1631; 
FAX (913) 841-2624. 

Trademarks: Windows/DOS Developer’s Jour¬ 
nal, R&D Publications, Inc. UNIX, AT&T Bell 
Laboratories. XENIX, MS-DOS, OS/2, Microsoft C 
and QuickC, Windows, CodeView, Microsoft. IBM, 
IBM-PC, International Business Machines Corp. 
Turbo C, Turbo Pascal, Turbo Debugger, Borland In¬ 
ternational. Macintosh, Apple Computer, Inc. Zortech 
C++, Zortech. Windows 3.0, Microsoft Corporation. 
dBASE, Ashton-Tate (Borland). NEC-9801, NEC. 


Page 4 - Windows/DOS Developer’s Journal 


From 

The Editor 

I once attended a talk by Donald Norman, author of The Design of 
Everyday Things, in which he advocated that user interfaces be designed by 
teams including at least one writer (and at least one psychologist, but I’ll 
only tackle one radical concept at a time). No one got up and left the room, 
but I knew that his dream was not going to be realized anytime soon in 
most software companies. Oh, we might form a team that, on paper, lists a 
writer as an equal team member, but would we have a writer contributing 
to software design decisions? Get real. 

I will go even one more step off the deep end and suggest that writers 
should contribute to design decisions even for software APIs that will only 
be seen by other programmers. My desire is entirely selfish - I would like 
to be faced with APIs that are easier to use and better documented than 
the ones I currently have to use. What would the Windows API be like if a 
writer had helped design it? 1 don’t know, but I can tell you this: there 
would not be 50,000 programmers trying to figure out what message to 
intercept to restrict the size of a window, and Charles Petzold would have a 
significantly smaller bank account. The point is, many design flaws become 
glaringly obvious when you have to document the design. 

There are a couple of reasons writers won’t be helping design software 
APIs anytime soon. First, the cost of inferior designs and documentation is 
easy to view as an intangible. No accepted metrics exist for estimating the 
amount of time wasted thumbing through API reference manuals. Second, 
the pool of qualified available writers is vanishingly small. You cannot ex¬ 
pect a writer without a strong technical background to generate good 
design ideas during a highly technical product design. In particular, for an 
API design team, you need someone who is primarily a writer and secon¬ 
darily a programmer. After all, how much detailed thought would you give 
to designing software or documentation for an API that you don’t under¬ 
stand well enough to use yourself? 

This is not the day of the writer, but that day is coming. It took us a long 
time to figure out that learning a programming language is not the same as 
learning to be a programmer. We will eventually figure out that good 
programs need good documentation, and the two are best designed 
together, not separately. Meanwhile, can anyone tell me what Child- 
WindowFromPointO is for, since MindowFromPoint() seems to return child 
windows just fine? I guess I’ll just keep thumbing through that API reference 
manual... 

Ron Burk 

Editor 
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A Reusable C++ Chunk Allocator 
For DOS And Windows 

Ron Burk and Helen Custer 


The Windows API offers memory management in the form 
of GlobalAlloc() and GlobalFreef) (along with the as¬ 
sociated locking and unlocking functions). These functions are 
not suitable for general-purpose memory management within 
your program, however, for two reasons. First, they are fairly 
slow and demand a significant space overhead for each 
memory allocation. Second, Windows 3.0 imposes a system- 
wide limit of about 8,000 memory handles returned by 
GlobalAlloc(). The standard solution is to create a memory 
manager that allocates one big chunk at a time using Global- 
Alloc() and then parcels it out one piece at a time. In this 
case, GlobalAlloc() acts like the UNIX function sbrk(). 

If you write large Windows programs in C++, you will 
probably use the large memory model in order to be able to 
conveniently create more than 64Kb of objects. Fortunately, 
large-model C++ programs work just fine with both the Zortech 
v3.0 and Borland C++ v3.0 compilers. Although large-model 
code generally runs more slowly than other memory models, 
you no longer have to scatter for and near modifiers 
throughout your code. Another convenience is that both Zor¬ 
tech and Borland supply versions of malloc()/free() and 
new/delete that allocate large chunks of memory with 
GlobalAlloc(), then parcel it out as discussed previously. 
Flowever, if your program spends a lot of time creating 
and destroying objects, you may want to improve on 
these default memory managers. 


Helen Custer is an author specializing 
in programming languages and operat¬ 
ing systems. She is currently writing a 
book about Microsoft Corporation's Win¬ 
dows NT operating system, to be pub¬ 
lished by Microsoft Press in 1992. 


Ron Burk has a B.S.E.E. from the 
University of Kansas and has been a 
programmer for the past 10 years. You 
may contact him at Burk Labs, P.O. Box 
3082, Redmond, WA 98073- 
3082. CIS: 70302,2 566. 
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Listing 1 (simple.c) 

linclude <stdlib.h> 

class Simple 
{ 

public: 

Simple ‘Next; 
int SomeData; 

void ‘operator new(size_t); 

void operator delete(void *, size_t); 
private: 

enum {PERCHUNK = 128); 

static Simple ‘FreeList; 

}; 

void ‘Simple::operator new(size_t Size) 

( 

Simple ‘Free = FreeList; 
if(Free) 

FreeList = FreeList->Next; 

else 

{ 

Free = (Simple *)new char[PERCHUNK*sizeof(Simple)]; 

FreeList = Free; 

for(int i = 1; i < PERCHUNK; ++i) 

( 

Free->Next ■ Free + 1; 

“Free; 

) 

Free->Next = 0; // NULL terminator 

Free = FreeList; 

} 

return Free; 

} 

void Simple::operator delete(void ‘Pointer, size_t) 

{ 

Simple ‘This = (Simple *)Pointer; 

This->Next = FreeList; 

FreeList = This; 

) 

/* End of File */ 


A Simple Chunk Allocator 



One of the advantages of using C++ 
is that you can overload the new and 
delete operators to take over the 
memory management for a specific 
class. C++ books often include examples 
of overloading new and delete to allo¬ 
cate memory in large chunks and then 
parcel out objects from those chunks as 
a means of reducing the number of 
times the slower, general-purpose 
memory allocator is called. Most books 
gloss over the problems inherent in this 
approach, however. This article fills in 
the gap between the textbook ex¬ 
amples and the realities of practical 
programming. We present a small, effi¬ 
cient, and reusable C++ class that you 
can easily add to your existing classes 
to speed up memory management. This 
class was designed for Windows, but 
can be used anywhere you need an ef¬ 
ficient memory manager. 

What Is A Chunk Allocator? 

A basic principle of memory 
management is that the more you 
know about how your program uses 
memory, the more efficient you can 
make your memory management code. 
For example, if you know that your 
code deallocates objects in exactly the 
reverse of the order in which they were 
allocated, then your memory manage¬ 
ment can consist of a large stack of 
memory and a stack pointer. Then, 
memory allocation is as simple and effi¬ 
cient as advancing the stack pointer by 
some number of bytes and deallocation 
just requires decrementing the stack 
pointer. Memory management doesn’t 
get much more efficient than that. 

Rather than create a different spe¬ 
cial-purpose memory manager for every 
C++ class you write, it would be better 
to develop a few customized memory 
managers that you can reuse with a 
wide variety of classes. The chunk al¬ 
locator described in this article is one 
such memory manager. 

When you start to write a special- 
purpose memory manager for a single 
C++ class, one advantage you have is 
that you know the size of the objects 
you will be allocating. For example, con¬ 
sider this simple class: 


class A { 
int data [4]; 
}; 
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With a 16-bit PC compiler, this class is 
exactly eight bytes long. You can use 
this information to build a memory 
manager that is faster than the stand¬ 
ard new and delete. 

A general-purpose memory manager 
has to handle all sizes of objects, from 
one byte to the maximum object size 
(64Kb on a PC). When it receives an al¬ 
location request, it has to first deter¬ 
mine if that number of contiguous 
bytes are available anywhere in its pool 
of free memory. A typical approach is 
to maintain a linked list of free memory 
and search that list for a chunk large 
enough to satisfy the request. Although 
memory may start as one big chunk, al¬ 
locations and deallocations of variable¬ 
sized objects over time turn it into a 
linked list of unevenly sized blocks. The 
list gets longer, and scanning the list for 
the required space consumes more 
time. The list may contain 10Kb of total 
free memory, but the largest con¬ 
tiguous block may be only 1Kb. In 
operating system jargon, the memory is 
“externally fragmented." In other words, 
you have memory that is not allocated, 
but does not do you any good. 

Chunk allocation uses a simpler ap¬ 
proach by taking advantage of the fact 
that it only allocates one size of object. 
The basic idea is to use the general- 
purpose allocator to allocate a chunk of 
memory that can hold many objects of 
the specified size. You also allocate 
enough extra memory for each object 
to hold a pointer. Next, treat the large 
chunk of memory as an array of objects 
and use the pointer field in each object 
to link it into a list of free objects. Then, 
memory allocation simply consists of 
taking an object off the free list and ad¬ 
vancing the free list pointer. Dealloca¬ 
tion consists of adding the object back 
to the free list. When the free list is 
empty and you need another object, 
you call the general-purpose allocator 
to get another chunk of memory and 
link each object within it into the free 
list. Figure 1 shows the state of a chunk 
allocator that has allocated and deallo¬ 
cated several objects and is currently 
using two chunks of memory. 
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Listing 1 shows an example similar to the one Bjarne 
Stroustrup uses in The C++ Programming Language to 
demonstrate overloading new and delete. In this listing, the 
class-specific operator new allocates and initializes a new 
array of objects, if necessary, but usually just advances the 
free list pointer and then returns the previous head object in 
the list. Notice that Simple: :new() ignores its Size parameter 
and assumes that it will only be called to allocate instances of 
class Simple. This simple bit of code can provide significantly 
faster memory management than a general-purpose scheme, 
but it has some irritating problems. 

The biggest drawback to this memory manager and those 
like it is that they can cause derived classes to fail at run 
time. Suppose that you derive a new class from the class 
shown in Listing 1, like this: 


class B : public Simple { 
short NewMember; 


Consider what happens now when you ask new to give you a 
new instance of class B. Since class B did not redefine the new 
operator, the compiler uses Simple::new() and, as noted ear¬ 
lier, that function assumes it only has to allocate objects of a 
fixed size. The result, of course, is eventual disaster as objects 
of class B overwrite other objects of cl ass B beneath them 
in the chunk of memory. 

The solutions to this problem are not terribly attractive. 
Some books suggest that you simply define a new operator for 
each derived class, changing only the size of the object each 
handles, if you follow that advice, not only do you waste code 
space on a little army of very similiar new operators, but your 
penalty for forgetting to define them will be hard-to-locate 
memory allocation errors. Even if you write a little preproces¬ 
sor (or use templates) to automate creating these new 
operators, it does not solve the problem of memory fragmen¬ 
tation. 

Each new operator like the one in Listing 1 maintains its 
own linked list of memory chunks that it shares with no other 
classes. Suppose that you have 50 classes, each using its own 
memory manager. Then suppose that class D happens to be 


Listing 2 (challoc.h) 

#ifndef CHALLOC H 

ChunkRoot *Root; 

Idefine CHALLOC H 

I: 


static ChunkRoot Roots[ChunkRoot::NUMBER OF BINS]; 

i. 

linclude <assert.h> 


linclude <stdlib.h> 

inline void ChunkAllocated:operator delete(void *Instance_) 

// challoc.h - header file for "chunk" memory allocator 

ChunkAllocated "Instance = (ChunkAllocated *)Instance_; 

ChunkRoot *Root = Instance->Root; 

class ChunkRoot 

Instance->Next = Root->FreeList; 

i 

Root->FreeList = Instance; 

public: 

ChunkRoot(size t ElementSize ); 

i 

~ChunkRoot(); 

inline void * ChunkAllocated::operator new(size t SizelnBytes) 

enum { 

i 

NUMBER OF BINS = 10, CHUNK SIZE = 4096, 

ChunkRoot *Root; 

MAX_0BJECT = CHUNK_SIZE/4 

ChunkAllocated *NewInstance; 

); 

assert(SizeInBytes < ChunkRoot::MAX OBJECT); 
if(SizelnBytes <= 2) 

private: friend class ChunkAllocated; 

Root = &Roots[0]; 

struct ChunkRootLink 

else if(SizelnBytes <= 4) 

f 

Root = &Roots[l]; 

ChunkRootLink *Next; 

else if(SizelnBytes <= 8) 

union 

Root = &Roots[2]; 

{ 

else if(SizelnBytes <= 16) 

long double LDAlign; 

Root = &Roots[3]; 

double DAlign; 

else if(SizelnBytes <= 32) 

long LAlign; 

Root = &Roots [4]; 

void *VAlign; 

else if(SizelnBytes <= 64) 

1: 

Root = &Roots[5]; 

void *Chunk() { return (void *)&LDA1ign; } 

else if(SizelnBytes <= 128) 

1; 

Root = &Roots[6]; 

void AddChunk(); 

else if(SizelnBytes <= 256) 

ChunkRootLink *Root; 

Root = &Roots[7]; 

ChunkAllocated *FreeList; 

else if(SizelnBytes <= 512) 

size t ElementSize; 

Root = &Roots[8]; 

size t ElementsPerChunk; 

else 

I; 

Root = &Roots[9]; 

if(!Root->FreeList) 

class ChunkAllocated 

Root->AddChunk(); 

i 

Newlnstance = Root->FreeList; 

friend class ChunkRoot; 

// Point back to root, so operator delete can find it 

public: 

Root->FreeList = NewInstance->Next; 

void *operator new(size t SizelnBytes); 

NewInstance->Root = Root; 

void operator delete(void *); 

return (void *)NewInstance; 

protected: 

i 

union 

#endif 

ChunkAllocated *Next; 

/* End of file */ 

Header File for Resuable Chunk Allocator 
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Figure 1 



A Chunk Allocator in Action 

Che same size as class H. If your program starts by allocating 
many objects of class D, frees most of them, and then allo¬ 
cates many objects of class H, you could run out of memory 
even though a lot of empty D chunks are sitting there unused. 
A fixed-size memory allocator does not cause any memory 
fragmentation for its own linked list of memory chunks, but it 
takes away memory from any other fixed-size memory al¬ 
locator. The result is the same: you run out of memory even 
though plenty of memory is available, a penalty many 
programs cannot afford to pay. 

A Better Chunk Allocator 

A better chunk allocator has to be reusable and not re¬ 
quire the user to redefine it for each class. A better chunk 
allocator must also allow distinct classes with similar sizes to 
share the same linked list of memory chunks. Fortunately, 
both of these problems have a common solution. Our solution 
is in Listing 2 ( challoc.h ) and Listing 3 (challoc.c). The rest of 
this section discusses how we arrived at this design. 

We started by assuming there must be an array of linked 
lists of memory chunks. Each element in this array points to a 
linked list of chunks for a particular object size. For example, 
the memory chunk array might have linked lists for objects of 
size 2 bytes, 4 bytes, 8 bytes, 12 bytes, 16 bytes, 24 bytes, 32 
bytes, 48 bytes, and so on. This means that if you allocate an 
object 6 bytes in length, it will come from the linked list of 
8-byte objects and 2 bytes go to waste. This scheme suffers 
from “internal fragmentation,” because each allocated block of 
memory may contain wasted bytes. Flowever, by judiciously 
selecting which object sizes to support, you can minimize in¬ 
ternal fragmentation for a given program. 

We created the class ChunkRoot to handle each linked list 
of memory chunks (see Figure 2). ChunkRoot keeps both a 
linked list of memory chunks and a pointer to the First free 
object within those memory chunks. The simplistic memory 
manager in Listing 1 never deletes memory chunks-, Chunk- 
Root keeps the extra linked list of chunks so that it can do so. 
The structure ChunkRootLink defines the simple structure of 
individual chunks: a linked list pointer followed by raw 
memory. The code uses a union to avoid alignment problems 



and uses casts as necessary to manipulate and initialize the 
raw memory block. ChunkRoot::AddChunk() is responsible for 
adding another chunk to a particular linked list of chunks. It 
links the block to Root and links the objects within the block 
to Free List. 

ChunkRoot should really be a private class - we do not 
want classes other than ChunkAllocated to create instances 
of ChunkRoot. As far as we can tell, C++ should allow us to 
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make ChunkRoot a private class. Unfortunately, C++ compilers 
continue to lag well behind the current language definition, 
and neither the Borland nor the Zortech compiler allows a 
static, initialized array of objects of a private class. One of the 
least pleasant aspects of programming in C++ is figuring out 
whether a particular construct is illegal, or merely not sup¬ 
ported correctly by the compiler at hand. 

ChunkRoot is pretty straightforward. The harder part was 
building an efficient, reusable mechanism for allowing classes 



to access the array of ChunkRoot objects. Assuming free ob¬ 
jects throughout a particular linked list of chunks will still be 
kept on a linked list of objects, each object must always have 
a pointer in it. Therefore, it is reasonable to start with a class 
that just has a pointer and let other classes inherit from it: 


class ChunkAllocated { 

class ChunkAllocated *Next; 
public: 

void ‘operator new(size_t); 

void operator delete( 
void*, size_t); 

}; 

Unlike the operator new in Listing 1, this one has to look 
at its Size argument and allocate an object from a linked list 
of memory chunks for objects greater than or equal to this 
size. Likewise, the operator delete has to return the object 
to the correct free list The challenge is to meet both these 
requirements and still keep the functions efficient. 

We made operator new an inline function and used a 
series of if statements to locate the correct linked list of 
memory chunks for a given size of object. On the surface, this 
looks suspect, but we based these choices on the way that 
C++ compilers tend to operate. We use a series of ifs rather 
than a switch statement because some compilers cannot 
generate inline code for a switch statement. With an inline 
function, most compilers are smart enough to detect at com¬ 
pile time that only one of the i/s is true, so they do not 
generate code for the other i/s or their branches. 

We also did not worry about the space penalty of having 
all those inline functions expanded because the optimized 
version of the inline new operator contains very little code. 
Also, most compilers generate code that calls a class-specific 
new at exactly one point - in the constructor for that class. 
With these compilers, then, a call to operator new just 
generates a call to the constructor, passing it a NULL this 
pointer, and the constructor contains the (implicitly-generated) 
code to call the new operator. 

Apart from these considerations, the reusable operator new 
is similar to the non-reusable version in Listing 1. The delete 
operator also must locate the correct linked list of memory 
chunks for the object being deleted. In addition, the compiler 
may generate code that passes the delete operator an incor¬ 
rect size argument because of pointer manipulations: 


class A {/*...*/}; 
class B:A {/*...*/}; 

B *b = new B; 

A *a = b; // legal 
delete a; // legal, but... 

// ... sizeof(A) passed 

A virtual destructor fixes this problem, but we did not want to 
add the overhead of a virtual table pointer to such a tiny, 
low-level class. Our solution to both of these problems was to 
ignore the size parameter and use a small trick. 
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The pointer in a chunk-allocated object would normally be 
unused while the object is allocated. We decided to make this 
pointer point to the linked list of memory chunks that the 
object was allocated from. That way, our operator delete 
could ignore its size parameter and directly place the object 
back on the correct ChunkRoot 's free list. Another side-effect 
of this trick is that it makes it easy to write a function that 
frees empty memory chunks. If each object within a particular 
chunk points to the ChunkRoot for that chunk, then that 
chunk can be freed. 


lates three times: the time spent in a loop doing no memory 
management at all, the time spent in a loop using the stand¬ 
ard new and delete operators, and the time spent in a loop 
using our chunk allocator. We compiled and ran the 
benchmark program as a Windows application; both compilers 
allow you to compile and run programs that use ordinary I/O 
functions like printf(). For the Borland compilation, we used 
the compiler options: 

-2 -02 -ml -WE -v- -P 


Performance 

We ran the simple benchmark program in Listing 4 
(bench.c) with both Borland C++ v3.0 and Zortech C++ v3.0. 
The program creates and deletes objects at random. It calcu- 


Listing 3 (challoc.c) 

linclude "challoc.h" 
linclude <assert.h> 
linclude <stddef.h> 

// Don't change without changing operator new 
// if/else statements as well! 

ChunkRoot ChunkAllocated::Roots 
[ChunkRoot::NUMBER_0F_BINS] = 

( 

2, 4, 8. 16, 

32, 64, 128, 256, 

512, 1024 

); 

ChunkRoot::ChunkRoot(size_t ElementSize_) 

: Root(NULL), FreeList(NULL), 
Element$ize(ElementSize_), 
ElementsPerChunk(CHUNK_SIZE/Element$ize ) 

( 

) 

// "ChunkRoot - Free linked list of chunks 
ChunkRoot::~ChunkRoot() 

( 

ChunkRootLink ‘Next, ‘Current = Root; 
whi le(Current) 

I 

Next = Current->Next; 
free((void *)Current); 

Current * Next; 

) 

) 


void ChunkRoot::AddChunk() 

I 

size_t Size * ElementSize * ElementsPerChunk 
+ offsetof(ChunkRootLink, LDAlign); 

ChunkRootLink ‘MallocResult = (ChunkRootLink *) 
ma11oc(Size); 

assert(MallocResult 1 = NULL); 

MailocResult->Next = Root; 

Root 1 MallocResult; 

char ‘BytePointer = (char *)MallocResult->Chunk(); 
for(int i » 1; i < ElementsPerChunk; ++i) 

( 

((ChunkAUocated *)BytePointer)->Next 

(ChunkAllocated*)(BytePointer+ElementSize); 
BytePointer +• ElementSize; 

) 

((ChunkAllocated *)BytePointer)->Next ■ FreeList; 
FreeList - (ChunkAllocated *)MallocResult->Chunk(); 

) 

/* End of File */ 


Source for Reusable Chunk Allocator 


and for Zortech, we used: 

-2 -a -g -bx -W2 -cpp -o+time 

Figure 3 shows the results. The gray area in each bar rep¬ 
resents the portion of the total time that was spent in 
memory management. As this figure shows, using this chunk 
allocator for a single class cut its memory allocation time ap¬ 
preciably-, the memory management speed in both cases 
more than doubled. With this algorithm, you can expect fairly 
constant memory allocation times for objects appreciably 
smaller than the chunk size. 

Although the speed is uniform for different objects, the 
amount of memory used is not. You can sometimes make 
significant changes in the total amount of memory your pro¬ 
gram uses by tuning the number and sizes of ChunkRoots. For 
example, if you know your program randomly allocates 
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Listing 4 (bench.c) 

linclude <stdlib.h> 
linclude <assert.h> 
linclude <stdio.h> 
linclude <time.h> 
linclude “challoc.h" 

int Random(int num) 

{ 

int Result - int(long(rand())*num/(RAND_MAX+l)); 
return Result < 0 ? -Result : Result; 

} 

class IntSet : public ChunkAl1ocated 

( 

public: 

IntSetO; 
int Foo[4]; 

); 

IntSet::IntSet() 

{ 

Foo[0] = Foo[l] * Foo[2] ■ Foo[3] * 0; 

}; 

class IntSet2 

{ 

public: 

IntSet2(); 
int Foo [4]; 

}; 

IntSet2::IntSet2() 

{ 

Foo[0] = Foo[l] = Foo[2] = Foo[3] = 0; 

}; 

const int MAXPOINTERS - 1024; 

const int MAXITERATIONS = 2048; 

IntSet *Pointers[MAXPOINTERS]; 

IntSet2 *Pointers2[MAXPOINTERS]; 

int main(int /*argc*/, char **/*argv*/) 

( 

int i, j, k; 

printf("Begin Benchmark\n“); 
time_t StartTime = time(NULL); 
for(j = 0; j < MAXITERATIONS; ++j) 
for(i « 0; i < MAXPOINTERS; ++i) 

if(Pointers[k=Random(MAXPOINTERS)]) 

Pointers[k] = NULL; 

float EmptyTime * difftime(time(NULL), StartTime); 
printff "empty loop time is %5.2f seconds\n", EmptyTime); 

StartTime * time(NULL); 
for(j = 0; j < MAXITERATIONS; ++j) 
for(i = 0; i < MAXPOINTERS; ++i) 

if(Pointers2[k=Random(MAXPOINTERS)]) 

( 

delete Pointers2[k]; 

Pointers2[k] = NULL; 

) 

el se 

( 

Pointers2[k] = new IntSet2; 
assert(Pointers2[k] != NULL); 

> 

float StandardTime = difftime(time(NULL), StartTime); 

printf( "Standard allocation time %5.2f seconds\n", StandardTime); 


Crude Benchmark for Memory Managment 


thousands of 6-byte objects and 
thousands of 8-byte objects, you may 
want to make a separate linked list of 
memory chunks for each size of object 
to avoid wasting two bytes for each 6- 
byte object. 

By dumping the object code 
generated, we verified that both com¬ 
pilers eliminated the big if/else state¬ 
ment in operator new-, both generated 
code that directly referred to the cor- 
rect element of the Chunk- 
Allocated: :Roots array. To keep the 
example code short, we used a relative¬ 
ly small array of ChunkRoots, but at the 
expense of wasted memory. Since each 
ChunkRoot handles objects twice the 
size of the previous one, an average of 
half the space in each object is wasted 
due to internal fragmentation (assuming 
your object sizes are uniformly dis¬ 
tributed). In practice, you would use 
more ChunkRoots, especially for smaller, 
more common, object sizes. That makes 
the if/else statement even longer, but 
the generated code is still as efficient. 

Drawbacks 

The ChunkAllocated class requires 
much less maintenance than the al¬ 
locator in Listing 1. By including the 
header file challoc.h and changing the 
declaration of your bottom-most class, 
you can enable chunk allocation for a 
whole inheritance tree of classes. One 
maintenance hassle that remains is in¬ 
itializing ChunkAllocated:: Roots []. If 
you change the object sizes in this 
array, you always have to remember to 
make a corresponding change to the if 
statements in operator new, or else 
the result will be a nasty runtime error. 
At least this problem is isolated to a 
single class. 

This allocator is slightly slower than 
the one shown in Listing 1, since it has 
to do a little more work to point the 
object back at the correct ChunkRoot: 
That is offset somewhat by the fact 
that this code does not require a virtual 
destructor for foolproof deletes, 
whereas variations on the scheme in 
Listing 1 do. The scheme in Listing 1 
also uses less memory, in the sense 
that you could use the Next field 
pointer for whatever you like while the 
object is in use. Our algorithm uses that 
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pointer both when the object is free (to 
point to the next free object) and when 
the object is allocated (to point to the 
ChunkRoot it came from). 

Summary 

Designing a reusable chunk allocator 
is an interesting problem. Programmers 
just learning C++ can be expected to 
create less-than-optimal solutions be¬ 
cause they are not aware of all the 
language's capabilities. However, the 
reverse is also true: you can become so 
fluent in new language constructs that 
you apply them even where simpler 
techniques are superior. Once we real¬ 
ized that we just needed a limited 
number of centralized memory pools, 
we were able to work out a reasonable 
implementation in C++. The difference 
between an academic algorithm and a 
reusable algorithm is sometimes just a 
little extra thought and effort. In this 
case, the improvement was definitely 
worth the effort. □ 


Listing 4 — Cont’d 


StartTime * time(NULL); 
for(j = 0; j < MAXITERATIONS; ++j) 
for(i = 0; i < MAXPOINTERS; ++i) 

if(Pointers[k=Random(MAXP0INTERS)]) 

( 

delete Pointersfk]; 

Pointers[k] = NULL; 

} 

el se 

( 

Pointersfk] = new IntSet; 
assert(Pointers[k] != NULL); 

} 

float ChunkTime = difftime(time(NULL), StartTime); 

printf( "Chunk allocation time %5.2f seconds\n", ChunkTime); 

printf( "Improvement = %5.2f %%\n“, 100.0 

* ((StandardTime-EmptyTime) - (ChunkTime-EmptyTime)) 

/ (StandardTime-EmptyTime)); 
return 0; 

) 

/* End of File */ 
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Windows Programming 


Fading-In Custom Controls 
For Windows 3 

Part I 


Victor R. Volkman 

Providing a visually effective and 
coherent handling of input and feed¬ 
back is the most rewarding part of 
developing software with a graphical 
user interface. In the Windows 
programming environment, the most 
basic building block of user interface 
construction is the control. Windows 
provides built-in support for six com¬ 
mon control classes: button, edit, 
listbox, combobox, scrollbar, and static. 
However, you can add your own totally 
independent "custom controls” to sup¬ 
plement these common classes. Once 
created and installed, your custom con¬ 
trols can participate and interact as 
smoothly and easily as the built-in 
ones, in this two-part article, I will cover 
the ideas behind custom controls and 
show how to create a "fader” custom 
control. In this part, I will cover most of 
the theory behind custom controls and 
demonstrate how to paint the fader 


control. Next month's installment will 
add the code needed to make the con¬ 
trol interact with dialog box editors and 
provide a demonstration program. 

Control Theory 

In Windows, a control is a standard 
child window that has been registered 
to participate as a component of the 
graphical user interface. Controls may 
receive input, display output, or perform 
both input and output. Controls are 
characterized by their high degree of 
specialization and focus. The button 
control class simply presents clickable 
boxes for yes or no and multiple-choice 
inputs. The button controls only 
produce output which reflects their cur¬ 
rent state. For example, the Check-Box 
subclass of Button displays an "X” in the 
on state and an empty rectangle in the 
off state. 


Victor R. Volkman received a BS in Computer Science from Michigan Technological 
University. He has been a frequent contributor to The C Users Journal since 1987. He is 
currently employed as Software Engineer at Cimage Corporation of Ann Arbor, 
Michigan. He can be reached directly at the HAL 9000 BBS (313) 663-4173 or as 
vrv@cimage.com on Usenet. 
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Controls can appear in a dialog box 
or any other window. The primary ad¬ 
vantage of using controls in a dialog 
box is that you can quickly define con¬ 
trols with a dialog box editor. If you dis¬ 
play controls in a window other than a 
dialog box window, then you must 
supply custom code to make the 
CreateWindow() calls for each individual 
control. Dialog boxes are defined as 
specialized pop-up windows containing 
one or more controls. 

If your application only needs a 
visually different type of control than 
the common controls provide, then you 
may be able to use owner-draw con¬ 
trols. However, if you need a functional¬ 
ly different type of control, then you 
should consider custom controls. 

Owner-Draw Controls 

The owner-draw Button control style 
(, BS_OWNERDRAU) is ideally suited for 
situations that require a graphical but¬ 
ton face. For example, you can create 
toolbars and toolbox palettes like those 
in popular Windows applications with 
sets of owner-draw buttons. Alternate¬ 
ly, you can use a set of similar owner- 
draw buttons together, as the Windows 
File Manager uses each folder button to 
represent a subdirectory. 

Owner-draw buttons differ from 
standard buttons only in that your ap¬ 
plication becomes responsible for every 



aspect of the button’s appearance: 
painting it, reacting to focus, selecting it, 
and enabling and disabling it. Since the 
entire owner-draw button interface is 
defined by the UM_ITEMDRAU message, it 
is one of the easiest customizations for 
the common controls. Petzold (1991) 
provides a complete example of how to 
implement an owner-draw button with 
a stretchable bitmap face. 

In addition to owner-draw buttons, 
Windows also supports two distinct 
styles of owner-draw list boxes. Owner- 
draw list boxes may have a fixed height 
for each item in the list 
(LBSJOUNERDRAUFIXED) or a height that 
varies between items (LBS_OWNERDRAU- 
VARIABLE ). If the list items are fixed- 
height and are ordinary strings 
(LBS_HASSTRINGS) or unsorted data, 
then you need to process 
WM_MEASUREITEM once. If you have a 
variable-height list box, then Windows 
will send you a UM_MEASUREITEM mes¬ 
sage every time you add an item 
(LB_ADDSTRING). Finally, if your list box is 
sorted ( LBS_S0RT) and does not contain 
strings, then Windows will send you 
many UM_C0MPARE1TEM messages as it 
asks you to help sort the contents of 
the list box. 
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Custom Controls 

A custom control is a specialized type of child window that 
handles all dialog messages appropriately and participates as 
a peer to other windows in a dialog box window environ¬ 
ment. To be fully generic, a custom control should be imple¬ 
mented as a DLL Once installed, a custom control is reusable 
by any application that understands its message interface. If 


Figure 1 



A Fader Custom Control in Action 



Figure 2 




Message 

Description 

Return 

wParam 

Lparam 



FDRM SETRANGE 

Set the range of 

N/A 

unused 

word: 




possible logical 



LO=min 




return values 



HI=max 



FDRM GETRANGE 

Get the current 

word: 

unused 

unused 




range of possible 

HI=max 






logical values 

LO=min 





FDRM SETLOGVALUE 

Set thumb to this 

N/A 

new 

unused 




new logical 


logical 





position 


value 




FDRM GETLOGVALUE 

Get the current 

cur. 

unused 

unused 




logical position 

logical 






of the thumb 

value 





FDRM SETPHYVALUE 

Set thumb to this 

N/A 

new 

unused 




new physical 


logical 





position 


value 




FDRM GETPHYVALUE 

Get the current 

cur. 

unused 

unused 




physcial position 

physical 






of the thumb 

value 





FDRN THUMBTRACK 

Sent to parent 

N/A 

fader 

word: 




window when thumb 


control 

HI=1 




has click/drag 


ID 

L0=han. 



FDRN ENDFADER 

Sent to parent 

N/A 

fader 

word: 




window when has 


control 

HI =2 




click/release 


ID 

LO=han. 


Programmer's Interface for Fader Custom Control 


Listing 1 (fader.h) 


/* Color number for WM_CTLC0L0R message */ 
♦define CTLCOLOR FADER 100 


/* Fader Button's class-specific window messages. */ 
♦define FDRM_SETRANGE (WMJJSER + 0) 

♦define FDRM_GETRANGE (WMJJSER + 1) 

♦define FDRM_SETLOGVALUE (WMJJSER + 2) 

♦define FDRM_SETPHYSVALUE (WMJJSER + 3) 

♦define FDRMJ3ETL0GVALUE (WMJJSER + 4) 

♦define FDRM GETPHYSVALUE (WM USER + 5) 


/* Fader Button's notification codes sent in HIWORD of IParam 
during a WM_C0MMAND message. */ 

♦define FDRNJTHUMBTRACK 1 

♦define FDRN ENDFADER 2 


/* Enables return of FDRNJTHUMBTRACK messages to parent. 

Should run faster if it doesn't have to send these */ 
♦define FDRS TRACK OxOOOlL 


Header File for Fader Custom Control 


Figure 3 


Message 

What the Fader does 

WM_GETDLGCODE 

Indicates it wants arrow keys only 

WM_CREATE 

Sets default logical range to 1...100 

Moves fader thumb to the top 

WM_PAINT 

Renders the control. If in drag mode, 
the thumb will be inverted 

WM_SETFOCUS 

Draws a caret in the middle of the thumb 
by inverting a slice 

UMJC ILL FOCUS 

Restores the client area by inverting 
the same slice 

WM_KEYDOWN 

Move thumb according to arrow key 

WM_LBUTTONDOWN 


WM_MOUSEMOVE 


WMJ.BUTTONUP 



Standard Messages Handled by Fader Custom Control 


Figure 4 


Identifier 

Value 

Object type 

CTLCOLOR_MSGBOX 

0 

Message box 

CTLCOLOR__EDIT 

1 

Edit control 

CTLCOLOR_LISTBOX 

2 

Listbox control 

CTLCOLOR_BTN 

3 

Button control 

CTLC010R_DLG 

4 

Dialog box 

CTLCOLOR_SCROLLBAR 

5 

Scrollbar control 

CTLCOLOR_STATIC 

6 

Static control 

CTLCOLOR_MAX 

8 

Only 3 bits are allowed 


Predefined CTLCOLOR Values from WINDOWS. H 
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you also add the appropriate library entry points, then it can 
interact with most dialog box editors, allowing the program¬ 
mer to select style bits and so forth. The best way to learn 
about custom controls is to dissect a fully developed example. 

The fader is a custom control designed to return a con¬ 
tinuous range of values based on the position of a thumb that 
slides along a rail (see Figure 1). The fader is similar to a Win¬ 
dows scrollbar in many respects. Since the standard scrollbar 
is almost inseparably associated with scrolling the client area, 
it quickly becomes unfamiliar in other contexts. The fader 
provides an analog range in the same way potentiometers are 
used in a stereo equalizer or mixer. In an application, a fader 
could be used to apply equalization to a waveform or to regu¬ 
late the hue of a color. 

Although a custom control is just another kind of window, 
there are some general design steps 
and rules of thumb that can make the 
implementation easier. The first step in 
designing a custom control should be to 
design the programming interface. The 
programming interface consists of both 
how the control communicates with 
the dialog box handler and what style 
flags it supports. 

Programming Interface: 

Messages 

Since Windows programming is mes¬ 
sage-based, it follows that a custom 
control child window will communicate 
primarily through messages. The parent 
dialog box function sets up the operat¬ 
ing parameters of the custom control 
via SendDlgltemMessagef). For ex¬ 
ample, the dialog box handler in the 
fader demo sends the FDRM_SETRANGE 
message to the fader. This message 
defines the upper and lower bounds of 
values it wants to receive from the 
fader. 

The custom control child window 
function reports back status and user 
interaction through a special message 
interface called a “notification." Notifica¬ 
tion messages are sent only from a 
child control to its parent window. The 
message ID for a notification is always 
WM COMMAND. The wParam parameter is 
always set to the sending control's 
dialog-box ID (each control in a dialog 
box usually has a unique integer iden¬ 
tifier). The high-order word of the l- 
Param contains the notification code 
and the low-order word contains the 
sending control's window handle [HUND). 

In the button control class, a button 
click sends a BN_CLICKED notification to 
the parent window. In the fader control 
class, there are two different notifica¬ 


tion codes to indicate user interaction. The fader control will 
send a FDRN_ THUMB TRACK notification whenever the user drags 
the thumb with the left-button held down. The control sends 
a FDRN_ENDFADER notification to indicate the end of a tracking 
sequence. These constants are defined in fader, h (Listing 1). 

The primary limitation of notifications is that there is no 
room left for information because the message parameters 
are predefined. This means the parent window has to send an 
inquiry message to get additional information. In the fader 
demo program, the dialog box function immediately replies 
with a FDRM_GETLOGVALUE when a FDRN_THUMBTRACK notifica¬ 
tion comes through. The overhead from these two extra mes¬ 
sage transactions causes a noticeable slowdown when com¬ 
bined with dragging animation. 
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Listing 2 (fader.c) 


linclude <windows.h> 
linclude “fader.h" 


Idefine NO_DRAG 0 /* Values of FADER_THUMBSTATE */ 

Idefine DRAG 1 


Idefine FADER THUMB OFFSET 2 


/* Window extra bytes */ 
Idefine FADER_RANGE 0 

Idefine FADERJALUE 4 

Idefine FADER_THUMBSTATE 6 

Idefine FADER WNDEXTRA 8 


HANDLE hGlobFaderlnstance = NULL; 
char szGlobControlName[] = “Fader"; 


/* Distance in pixels from edge */ 


/* logical range values returned */ 
/* Current logical value */ 

/* DRAG or N0_DRAG */ 

/* Total I of window extra bytes */ 


/* Forward declarations for completeness */ 

static BOOL NEAR PASCAL RegisterControlClass (HANDLE hlnstance); 

LONG FAR PASCAL FaderWndFn (HWND hWnd, WORD wMsg, 

WORD wParam, LONG IParam); 

int GetThumbHeight(int iTotalHeight); 

void GetFaderThumbRect(HWND hWnd, LPRECT pRc, LPRECT pThumbRect, 
int iCurPos); 

int XlatPosPhysicalToLogical(LONG lLogRange, int iPhysMax, 
int iPhysMin, int iCurPos); 

int XlatPosLogicalToPhysical(LONG lLogRange, int iPhysMax, 
int iPhysMin, int iLogPos); 

static void DrawCaret(HDC hDC, LPRECT lprc); 

static void PaintFader(HWND hWnd); 


/* These are DLL initialization and control functions */ 


BOOL FAR PASCAL LibMain (HANDLE hModule, WORD wDataSeg, 
WORD wHeapSize, LPSTR IpszCmdLine) 

{ 

hGlobFaderlnstance = hModule; 
if (wHeapSize != 0) /* Moveable DS */ 

UnlockData(O); 

return RegisterControlClass(hModule); 


int FAR PASCAL WEP (int nSystemExit) 

f 

UnregisterClass(szGlobControlName, hGlobFaderlnstance); 
return 1; /* never fails */ 

) 


/* This function can be static if you only plan to use it 
in a DLL */ 


BOOL NEAR PASCAL RegisterControlClass (HANDLE hlnstance) 

{ 

WNDCLASS wc; 


wc.Style » CS_GLOBALCLA$S | CS_HREDRAW | CS_VREDRAW; 

wc.lpfnWndProc = FaderWndFn; 

wc.cbClsExtra = 0; 

wc.cbWndExtra = FADER_WNDEXTRA; 

wc.hlnstance = hlnstance; 

wc.hlcon * NULL; 

wc.hCursor » LoadCursor(NULL, IDCSIZENS); 

wc.hbrBackground = C0L0R_W1ND0W + 1; 
wc.lpszMenuName = NULL; 
wc.lpszClassName = szGlobControlName; 
return RegisterClass(&wc); 


Main Code for Fader Custom Control 


Drawing up a table of messages, 
parameters, and notification codes 
specific to your control will help clarify 
how the control interacts with its parent 
Figure 2 shows a table that describes the 
behavior of the fader control. 

Programming Interface: Styles 

While the message protocol defines 
the dynamic behavior of the custom 
control, the style flags define its inter¬ 
face characteristics. You can either set 
the style flags directly in the Create- 
Uindowf) call in an application or in¬ 
directly via the Style dialog box in a 
dialog box editor. A custom control's 
style resides in a single 32-bit word. The 
high 16-bit word contains window 
styles that are common to all kinds of 
windows such as WS_MAXIMIZE, US_BOR- 
DER, WS_VSCROLL, and so on. The low 
16-bit word is free for class-specific 
style bits. For example, the 
LBS_HASSTRINGS and LBS SORT Style 
bits mentioned earlier are specific to 
the list box class. Note that the letter 
“S" in LBS_ and US_ denotes style flags. 

Some style flags only affect the 
visual appearance of the control. For ex¬ 
ample, the LBS_B0RDER style flag on the 
list box simply specifies that a bounding 
rectangle should appear around the list 
box. Other times the style flags 
delineate a major functional difference 
in the message protocol. For example, 
the LBS_NOTlFY style flag on a list box 
tells whether a message will be sent to 
the parent when the user selects an item. 

Although it is possible to change the 
style of an active control, it is usually 
done only in special circumstances. For 
example, you might want to change a 
control from a standard push button 
(BS_PUSHBUTTON) to become the default 
push button (BS_DEFPUSHBUTTON) to reflea 
a change in the state of the application. 

A fader custom control has several 
possibilities for style bits. You could cre¬ 
ate a FDRS_HORZ style to designate a 
horizontal (left-to-right) fader and a 
FDRS_VERT style to designate a vertical 
(top-to-bottom) fader. You could use a 
FDRS_NOTIFY style to enable or disable 
the FDRN_ THUMBTRACK notification mes¬ 
sages. A FDRS_NOSCALE style bit could 
be used to disable the tick marks dis¬ 
played along the axis. Although all of 
these are good candidates for class- 
specific style bits, the control in this 
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article only implements the 
FDRSJOTIFY style. 

User Interface 

After defining the programming in¬ 
terface, you can begin to design the 
user interface. Most controls, with the 
exception of status windows, require 
some kind of user interaction. The more 
types and modes of interactions that 
your control allows, the more complex 
your code will be. For example, a push 
button has a relatively simple and well- 
defined interface: you just click on it. 
However, a spin button might include 
multiple hot spots, a drag mode, 
double-clicks, and even timer-activated 
events. The fader user interface is more 
complex than a push button, but 
simpler than a spin button. A single 
click in any area of the control snaps 
the thumb to the mouse position. A 
click-and-hold on the thumb itself 
enters a drag mode until the left mouse 
button is released. 

Whenever possible, you should at¬ 
tempt to mimic the look and feel of ex¬ 
isting windows controls. The guidelines 
for the look of a custom control are 
mostly common sense. You might want 
to browse the IBM Common User Ac¬ 
cess (CUA) GUI standards book for in¬ 
spiration. If your control accepts any 
kind of user input, then it should 
respond to selection ( WM_ENABLE) and 
focus (UMJET FOCUS). 

With the enormous variety of com¬ 
puters today, from tiny palm-top com¬ 
puters to giant tower PCs, the end user 
could have almost any combination of 
input devices. Your user might have 
just a keyboard or a keyboard and a 
mouse, trackball, joystick, or even a 
pen. However, if your control is equally 
responsive to keyboard and mouse, 
then it will work with any other point¬ 
ing devices. If you want to support users 
without mice, your control must respond 
to the DLGCJANTKEYS message. 

Controls should look good at any 
resolution, color depth, and aspect ratio. 
Remember that you can configure any 
VGA display card for CGA 640x200, EGA 
640x350, and VGA 640x480 resolutions. 
Testing at CGA resolution also checks 
out the ability of the control to perform 
with a true monochrome bitmap. For 
completeness, you should test the con¬ 
trol in a 256-color mode and even with 


Listing 2 — Cont'd 


/* This function is handy for sending the FDRN_... messages 
back to the parent. Note that FDRN_THUMBTRACK is disabled 
unless FDRS_TRACK is enabled */ 

static LONG NEAR PASCAL NotifyParent (HWND hWnd, 

WORD wNotifyCode) 

{ 

BOOL bSend=TRUE; 

if (wNotifyCode == FDRN_THUMBTRACK) 

bSend = (BOOL) (GetWindowLong(hWnd, GWL_STYLE) & FDRSTRACK); 


COMPUTER 

LANGUAGE 
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struct { int a[3], b; ) w[] = { { 1, 2, 3 ), 2 }; 
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Listing 2 — Cont’d 

if (bSend) 

return SendMessage(GetParent(hWnd), WM_COMMAND, 
GetWindowWord(hWnd, GWW_ID), 
MAKELONG(hWnd, wNotifyCode)); 

else 

return 0; 


/* This is the main “window function" procedure, it is called 
sometimes by the SDK Dialog box editor */ 

LONG FAR PASCAL FaderWndFn (HWND hWnd, WORD wMsg, 

WORD wParam, LONG IParam) 

{ 

LONG 1 Result = 0; 

HDC hDC; 

POINT pt; 

RECT rc; 
int iLogPos; 
int i01dLogPos; 
int iPhyPos; 
int iMaxLog; 
int iMinLog; 

RECT thumb_rect; 

LONG lLogRange; 
int iThumbHalf; 

HANDLE hNewBrush, hOldBrush; 

switch (wMsg) { 
case WM_CREATE: 

SendMessage(hWnd, FDRM_SETRANGE, 0, MAKELONG(0, 100)); 

SendMessage(hWnd, FDRM_SETLOGVALUE, 0, 0); 

break; 

case WM_GETDLGCODE: /* interface query by dialog manager */ 

1 Result = DLGC_WANTARROWS; 
break; 

case WM_PAINT: 

PaintFader(hWnd); 
break; 

case WM_SETFOCUS: /* receiving the keyboard focus */ 
case WM_KILLFOCUS: /* losing the keyboard focus */ 

/* calculate update region */ 

GetClientRect(hWnd, &rc); 
iLogPos = GetWindowWord(hWnd, FADER_VALUE); 
GetFaderThumbRect(hWnd, (LPRECT)&rc, (LPRECT)&thumb_rect, 
iLogPos); 

if (thumb_rect.left ** rc.left) 
break; 

/* force a repaint */ 
hoc = GetDC( hWnd ); 
if (hDC) ( 

/* define appropriate brush & text colors */ 
if (hNewBrush » (HBRUSH)SendMessage( GetParent(hWnd), 
WM_CTLCOLOR, hDC, MAKELONG(hWnd,CTLCOLOR_BTN) ) ) 
hOldBrush * SelectObject(hDC,hNewBrush); 
else 

hOldBrush = NULL; 

/* draw caret */ 

DrawCaret(hDC, (LPRECT)&thumb_rect); 

/* restore original brush */ 
if ( hNewBrush ) { 

SelectObject( hDC, hOldBrush ); 

DeleteObject( hNewBrush ); 

) 


a 15-bit color VGA card (e.g., ATI 
VGA/Wonder XL) if possible. 

Once an instance of a control is 
defined, it will be the same size relative 
to other controls and windows regard¬ 
less of the screen resolution. If your 
control is to be fully generic, then it 
must be sizeable. Therefore, you will 
need to test it out at a variety of sizes 
from as tiny to as large as practical. If 
your control has a lot of detailing, such 
as 3-D effects or grid lines, then you 
may want to paint it differently based 
on its size. The fader control sensibly 
omits 3-D shading if it finds that the 
thumb is less than four pixels tall. 

If you stick to using the predefined 
system colors, you will have the best 
results with the least amount of effort. 
For example, naming the window back¬ 
ground color explicitly (C0L0R_BACK- 
GROUND) rather than assuming it is white 
is the safest. Similarly, you can also as¬ 
sume that the window frame color 
(COLOR_U IN DOM FRAME) contrasts with the 
window background color. You should 
consider allowing the parent window to 
influence the color of the control by 
supporting the UM_CTLC0L0R message. 
Buttons have special paint colors which 
I will elaborate on later. 

Welch (1990) specifically discourages 
displaying bitmaps inside of custom 
controls. The primary disadvantage of 
bitmaps is that your custom control will 
have to scale them with StretchBlt() 
to accommodate different resolutions as 
Petzold (1991) has done. The distortion 
due to stretching will render your con¬ 
trol blocky at best and illegible at 
worst. This effectively limits your con¬ 
trol to the original size of the bitmap. 
Vector-oriented paint functions, such as 
LineTo(), render images that are scal¬ 
able over a much wider range with 
minimal degradation. 

The Window Function 

The window function is the heart of 
every Windows application. The win¬ 
dow function is called directly by the 
Windows kernel and receives a stand¬ 
ard set of parameters. Its major respon¬ 
sibility is to dispatch each message and 
return its results back to the kernel. 
This is equally true for custom controls. 
Custom control child windows must 
process the same basic messages, such 
as WM_CREATE and UM_PAINT, that stand¬ 
ard windows handle. Additionally, some 
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messages are unique to custom con¬ 
trols and some messages need special 
handling by them. Figure 3 gives a cap¬ 
sule summary of the Windows mes¬ 
sages that the fader control handles. 

It is possible and probable that 
several instances of a single control can 
be active within the same dialog box 
and even in different applications. 
Therefore, you must make all your cus¬ 
tom control code re-entrant. The most 
important design consideration is that 
you must completely avoid global data. 
This means using only local stack and 
heap variables for immediate storage. 
You can maintain data that must sur¬ 
vive between calls to the window func¬ 
tion by defining window extra bytes, 
property lists, or atoms. Since the fader 
control only needs eight bytes of state 
information, the window extra bytes 
are sufficient to store everything. The 
advantage of window extra bytes is 
that they are automatically allocated 
and deallocated with the window hand¬ 
le. The disadvantage is that the extra 
bytes consume precious memory in 
Windows' USER heap. 

The First message the fader window 
function handles is the UM_CREATE mes¬ 
sage (see Listing 2). Normally, this is 
where you would place dynamic alloca¬ 
tion for property lists or similar objects. 
The fader uses SendMessagef) to per¬ 
form two tasks as if they were initiated 
by the parent window. The 
FDRM_SETRANGE message sets the range 
of logical values at the top and bottom 
of the fader from 1 to 100 respectively. 
The FDRM_SETPHYVALUE message moves 
the thumb up to the very top of the slot 

Soon after the UM_CREATE message, a 
custom control window function can 
expect to receive a UM_GETDLGCODE 
query from the dialog box manager. If 
your control expects to receive no key¬ 
board input, then you can simply set Z- 
Result to DLGC_STATIC. Other pos¬ 
sibilities are arrow keys (WANT_ARROW), 
tab keys ( UANT_TAB), or all keys 
(UANT_ALL). The tab key is usually best 
left for the dialog box manager to 
process. If your control emulates fea¬ 
tures of one of the common classes, 
you can enable messages specific to 
their types as well. The fader window 
function asks only for arrow keys 
(UANT_ARROH) and processes the result¬ 
ing UM_KEYD0UN messages. 


Listing 2 — Cont’d 

/* release display context */ 

ReleaseDC( hWnd, hDC ); 

I 

break; 

case WMJCEYDOWN: /* process virtual key code */ 

GetClientRect(hWnd, Src); 

iLogPos = (int)GetWindowWord(hWnd, FADER_VALUE); 

iOldlogPos * iLogPos; 

lLogRange ■ GetWindowLong(hWnd, FADER_RANGE); 

iMaxLog * HIW0R0(1LogRange); 

iMinLog * L0W0RD(1LogRange); 

switch (wParam) { 

case VK_H0ME : /* home key */ 
iLogPos ■ iMinLog; 
break; 

case VK_END : /* end key */ 
iLogPos ■ iMaxLog; 
break; 

case VK_LEFT : /’ cursor left key */ 
case VK_D0WN : /* cursor down key */ 
if (iLogPos < iMaxLog) 
iLogPos++; 
break; 

case VK_UP : /* cursor up key */ 
case VK_RIGHT : /* cursor right key */ 
if (iLogPos > iMinLog) 
iLogPos--; 
break; 

case VK_PRI0R : /* page up key */ 

iLogPos -« (iMaxLog - iMinLog) / 8; 
if (iLogPos < iMinLog) 
iLogPos - iMinLog; 
break; 

case VK_NEXT : /* page down key */ 
iLogPos += (iMaxLog - iMinLog) / 8; 
if (iLogPos > iMaxLog) 
iLogPos * iMaxLog; 
break; 

default : /* something else */ 
break; 

) 

if (iLogPos != iOldLogPos) /* did it change? */ 

( 

SendMessage(hWnd, FORM SETLOGVALUE, iLogPos, 0); 
NotifyParent(hWnd, FDRN_THUMBTRACK); 

/* Invalidate old position */ 

GetFaderThumbRect(hWnd, (LPRECT)&rc, 

(LPRECT)&thumb_rect, iOldLogPos); 

InvalidateRect(hWnd, (LPRECT)&thumb_rect, TRUE); 

/* Invalidate new position */ 

GetFaderThumbRect(hWnd, (LPRECT)&rc, 

(LPRECT)&thumb_rect, iLogPos); 

InvalidateRect(hWnd, (LPRECT)&thumb_rect, TRUE); 

} 

break; 

case WM_LBUTT0ND0WN: 

GetClientRect(hWnd, &rc); 

iLogPos = GetWindowWord(hWnd, FADER_VALUE); 

GetFaderThumbRect(hWnd, (LPRECT)Src, (LPRECT)&thumb_rect, iLogPos); 

pt * MAKEPOINT(lParam); 
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Listing 2 — Cont’d 

/* is the mouse in the “hot" rectangle? */ 
if ((thumb_rect.top <= pt.y) && (thumb_rect.bottom >= pt.y) && 
(thumb_rect.left <= pt.x) && (thumb_rect.right >* pt.x)) { 

SetWindowWord(hWnd, FADER_THUMBSTATE, DRAG); 
hDC = GetOC(hWnd); 

InvertRect(hDC, (LPRECT)&thumb_rect); 

ReleaseDC(hWnd, hDC); 

NotifyParent(hWnd, FDRN_THUMBTRACK); 

/* grab focus if necessary */ 
if ( GetFocus() != hWnd ) 

SetFocus( hWnd ); 

/* Lock mouse on to this window */ 

SetCapture(hWnd); 

) 

break; 

case WM_M0USEM0VE: 
case WM_LBUTTONUP: 

/* Nothing to do if not in drag! */ 
if ((wMsg == WM_M0USEM0VE) && 

(GetWindowWord(hWnd, FADER_THUMBSTATE) != DRAG) ) { 

IResult * DefWindowProc(hWnd, wMsg, wParam, IParam); 
break; 

} 

/* set the new current position and ask for redraw */ 
pt = MAKEPOINT(lParam); 

GetClientRect(hWnd, &rc); 

iLogPos * GetWindowWord(hWnd, FADER_VALUE); 

lLogRange = GetWindowLong(hWnd, FADERRANGE); 

/* Invalidate old position */ 

GetFaderThumbRect(hWnd, (LPRECT)&rc, (LPRECT)&thumb_rect, iLogPos); 
InvalidateRect(hWnd, (LPRECT)&thumb_rect, TRUE); 

iPhyPos = pt.y; 

iThumbHalf 1 GetThumbHeight(rc.bottom)/2; 
if (iPhyPos < iThumbHalf) 
iPhyPos * iThumbHalf; 
if (iPhyPos > rc.bottom-iThumbHalf) 
iPhyPos * rc.bottom-iThumbHalf; 

iLogPos « XlatPosPhysicalToLogical(lLogRange, 

rc.bottom-iThumbHalf, rc.top+iThumbHalf, iPhyPos); 
GetFaderThumbRect(hWnd, (LPRECT)&rc, (LPRECT)&thumb_rect, iLogPos); 
InvalidateRect(hWnd, (LPRECT)&thumb_rect, TRUE); 

SetWindowWord(hWnd, FADER_VALUE, iLogPos); 

NotifyParent(hWnd, FDRN_THUMBTRACK); 

if (wMsg == WM_LBUTTONUP) ( 

SetWindowWord(hWnd, FADER_THUMBSTATE, N0_DRAG); 
NotifyParent(hWnd, FDRN_ENDFADER); 

ReleaseCapture(); 

} 

break; 

case FDRM_SETRANGE: 

GetClientRect(hWnd, &rc); 

InvalidateRect(hWnd, (LPRECT)&rc, TRUE); 

SetWindowLong(hWnd, FADER_RANGE, IParam); 
break; 

case FDRM_GETRANGE: 

IResult « GetWindowLong(hWnd, FADER_RANGE); 
break; 

case FDRM_SETLOGVALUE: 

GetClientRect(hWnd, Src); 

InvalidateRect(hWnd, (LPRECT)&rc, TRUE); 

SetWindowWord(hWnd, FADER_VALUE, wParam); 
break; 


The UM_KEYDOUN message carries the 
virtual key code in its wParam argument. 
The fader window function moves the 
thumb up or down according to the 
direction of the arrow key. By conven¬ 
tion, the fader moves the thumb in logi¬ 
cal units rather than physical units. 
Since the actual physical size of the 
custom control child window may be 
arbitrarily small, the mouse positioning 
may not provide a fine enough control. 
Logical unit measurement, in conjunc¬ 
tion with the keyboard input, allows 
the control to simulate a finer resolu¬ 
tion. Thus, a control only 20 pixels tall 
could return values from i to 1000. The 
range of logical values should always be 
greater than the range of physical 
values, for best performance. 

The virtual key codes in the fader 
work roughly the same as they do in a 
scrollbar. The PgUp ( VK_PRI0R ) and PgDn 
(VK_NEXT) keys move the thumb one- 
eighth of the way up or down the slot. 
The up-arrow (VK_UP) and right-arrow 
( VK_RIGHT) push the thumb up one logi¬ 
cal value. Similarly, the down-arrow 
( VK_D0WN) and left-arrow ( VK_LEFT) push 
the thumb down one logical value. The 
incremental keys will not necessarily al¬ 
ways produce a visible change in the 
thumb position. Finally, the Home 
( VK_H0ME) and End ( VK_END) keys move 
the thumb to the minimum and maxi¬ 
mum logical positions respectively. 

A custom control that accepts input 
should work with the mouse as well as 
with the keyboard. The fader window 
function accepts mouse clicks from the 
left mouse button to both set and drag 
the thumb. It does this by processing 
UM_ LBUTT0ND0WN, UM_M0USEM0VE, and 
HM_LBUTT0NUP messages. The window 
function maintains the drag state in the 
window extra bytes at offset 
FADER_ THUMBSTA TE. 

The UM_LBUTT0ND0HN message ar¬ 
rives as soon as the user clicks down 
on the left mouse button. The fader 
window function determines whether 
or not the click was in the thumb area. 
If the thumb was clicked, the fader 
enters the drag state until it receives a 
MM_LBUTT0NUP message. The control 
visually displays the drag state by in¬ 
verting the image of the thumb control. 
The control defers all additional 
processing until it receives a UM_LBUT- 
TONUP or UM_M0USEM0VE message. 
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The fader window function handles 
UM_LBUTTONUP and UM_M0USEM0VE mes¬ 
sages in the same case statement to 
emphasize their similarity. The control 
ignores UM_M0USEM0VE messages unless 
the thumb is being dragged. The win¬ 
dow function animates the thumb by 
redrawing it each time a UM_M0USEM0VE 
is received in drag mode. For the 
UM_PAINT to work properly, you must 
invalidate both the old and new rec¬ 
tangles that the thumb occupied. At 
each mouse movement, the control 
sends a FDRN_ THUMBTRACK notification 
message to the dialog box handler. The 
FDRN_ THUMBTRACK notification is for ap¬ 
plications that want live feedback 
during control manipulation. This would 
be useful when controlling volume, for 
example. Appliations that do not need 
live feedback can ignore the 
FDRN_ THUMBTRACK notification and listen 
for the FDRN_ENDFADER notification in¬ 
stead. The FDRN_ENDFADER notification is 
sent after exiting drag mode, a single 
click occurs anywhere else, or the user 
presses a valid arrow key. 

In addition to all the WM_ system 
messages, the fader window function 


Listing 2 — Cont'd 


case FDRM_GETLOGVALUE: 

IResult = GetWindowWordfhWnd, FADER_VALUE); 
break; 

case FDRM_GETPHYSVALUE: 

GetClientRectfhWnd, &rc); 

iThumbHalf = GetThumbHeight(rc.bottom)/2; 

HogRange = GetWindowLong(hWnd, FADER_RANGE); 
iLogPos ■ GetWindowWordfhWnd, FADER_VALUE); 

IResult = (long) XlatPosLogicalToPhysical(1LogRange, 
rc.bottom-iThumbHalf, rc.top+iThumbHalf, ilogPos); 
break; 

case FDRM_SETPHYSVALUE: 

GetC11entRect(hWnd, &rc); 

iThumbHalf * GetThumbHeight(rc.bottom)/2; 

HogRange = GetWindowLong(hWnd, FADER_RANGE); 
iLogPos * XlatPosPhysicalToLogical (HogRange, 

rc.bottom-iThumbHalf, rc.top+iThumbHalf, wParam); 
SetWindowWord(hWnd, FADER_VALUE, iLogPos); 

InvalidateRect(hWnd, NULL, TRUE); 
break; 

default: 

IResult = DefWindowProc(hWnd, wMsg, wParam, IParam); 
break; 

) 

return(lResult); 


For small business 
systems developers 


Spectrum is a muti-user client-server 
environment created especially for small 
businesses with a need for developing 
customized applications. 

The Spectrum environment includes all 
tools needed to create your customized 
small business system, including: 

> 1 0O user Spectrum server 

> network terminal software 

> Spectrum program compiler 

> program editor 

Hardware requirements: 

> ISM XT or compatible 

> terminals: &A-OK RAM 

> server: 1 to 12M expanded RAM, 
depending on number of usrs 

> network adapters with NETSIOS 
drivers (which come with most network 
software and even some adapters) 

Cad Spectrum Data Systems at (504)887-0198 for C.O.D. 
orders ($250 pCus p&h) or to face an information packet 
sent to you. Cad between 5 & 6 Central time with 
technical questions. 60 day money-back, guarantee. 


The $25 Network 


Try the 1st truly low cost IAN 

* Connect 2 or 3 PCs, XTs, ATs, PS/2s 

* Uses serial ports and 5 wire cable 

* Runs at 115K baud, up to 90 feet 

* Transfer 8500 bytes per second (ATs) 

* Runs in background, totally transparent 

* Share any device, any file, any time 

* Needs only 15K of ram 

* Just $25 per network, NOT PER NODE! 

* Replace all file transfer software 

* Version 2.3M now has TinyMAIL 

* OVER 20,000 SOLD WORLDWIDE 


Skeptical? We make believers! 


Information Modes 

P.O. Drawer F 
Denton, TX 76202 
817-387-3339 Techline 

1-800-628-7992 Orders 



□ Request 159 on Reader Service Card □ □ Request 295 on Reader Service Card □ 
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Listing 2 — Cont’d 

/* This is a "helper" function which draws the entire fader */ 

static void PaintFader(HWND hWnd) 

{ 

PAINTSTRUCT ps; 

HANDLE hOldPen; 

HANDLE hNewBrush, hOldBrush; 

HANDLE hMyParent; 

RECT thumb_rect; 
int x_center, y_coord; 
int iLogPos; 
int iPhyPos; 
int iThumbHalf; 

LONG lLogRange; 

HDC hDC; 

RECT rc; 

/* Default system color is C0L0R_BTNFACE from WNOCLASS structure */ 
hDC = BeginPaint(hWnd, &ps); 

GetClientRect(hWnd, &rc); 

hOldPen ■ SelectObject( hDC, 

CreatePen(PS_SOLID,l,GetSysColor(COLOR_WINDOWFRAME)) ); 

/* define appropriate brush & text colors */ 
hMyParent = GetParent(hWnd); 

if (hNewBrush = (HBRUSH)SendMessage( hMyParent, WM_CTLC0L0R, 
ps.hdc, MAKELONG(hWnd,CTLCOLOR_FADER) ) ) 
hOldBrush = SelectObject(ps.hdc,hNewBrush); 
else 

hOldBrush = NULL; 

/* Draws with horizontal symmetry */ 
x_center « rc.right / 2; 

/* draw fader slot (clockwise) */ 

MoveTo(hDC, x_center, 1); 

LineTojhDC, x_center+l, 2); 

LineTo(hDC, x_center+l, rc.bottom-2); 

LineTo(hDC, x_center, rc.bottom-1); 

LineTo(hDC, x_center-l, rc.bottom-2); 

LineTojhDC, x_center-l, 2); 

LineTo(hDC, x_center, 1); 

/* draw gridlines (top to bottom, left to right) */ 
for (y_coord=3; y_coord < rc.bottom-3; y_coord+=3) ( 

/* Left half first */ 

MoveTo(hDC, 1, y_coord); 

LineTo(hDC, x_center-l, y_coord); 

/* Then right half */ 

MoveTo(hDC, x_center+2, y_coord); 

LineTo(hDC, rc.right-1, y_coord); 

} 

/* draw filled box and then dividing line */ 
iThumbHalf = GetThumbHeight(rc.bottom)/2; 
iLogPos = GetWindowWord(hWnd, FADER_VALUE); 
lLogRange = GetWindowLong(hWnd, FADFR_RANGE); 

iPhyPos « XIatPosLogicalToPhysical(1LogRange, rc.bottom-iThumbHalf, 
rc.top+iThumbHalf, iLogPos); 

GetFaderThumbRect(hWnd, (LPRECT)&rc, (LPRECT)&thumb_rect, iLogPos); 

/* restore original brush */ 

DeleteObject( SelectObject(hDC,hOldBrush) ); 

/* now go to 3D button face brush */ 
hOldBrush = SelectObject( hDC, 

CreateSolidBrush(GetSysColor(COLOR_BTNFACE)) ); 


supports several unique messages: 
FDRMJETRANGE, FDRM_GETRANGE, 

FDRM_ SETLOGVALUE, FDRM_GETLOGVALUE, 
FDRM_ SETPHYVALUE, and FDRM_GET- 
phyvalue. Figure 2 briefly describes the 
inputs and outputs for these messages. 
The first four functions get and set the 
logical range and current logical values 
of the fader. 

The FDRM_SETRANGE message forces 
a redraw of the entire child window 
rather than attempting to manually 
compute the correct rectangles. The 
FDRM_GETRANGE message only has to 
fetch and return the values directly 
from the window extra bytes. Because 
the fader is intended to be more of an 
input control than an output window, 
the FDRMSETLOGVALUE is normally 
called once by the dialog box handler 
to set the initial value. This is why it 
forces a redraw as FDRM_SETRANGE does. 
The FDRM_GETLOGVALUE message only 
needs to return window extra bytes. 

I included the last two messages, 
FDRM_ SETPHYVALUE and FDRM_GET- 
PHYVALUE, for the sake of completeness. 
For most applications, the logical value 
interface is sufficient. The physical 
values might be helpful if the faders 
were resized or were otherwise bound 
to some other object on the screen. 

Painting The Fader 

In addition to all the aforementioned 
messages, the window function must 
also act on the HM_PAINT message. The 
HM_PAINT message is special in that it 
has a lower priority than other mes¬ 
sages in the queue. It is also the only 
message in which you can use the 
BeginPaint()/EndPaintf) construct. 
Due to the amount of code required, I 
store the painting code outside the win¬ 
dow function in PaintFaderf). 

On entry to PaintFaderf) , the back¬ 
ground brush color defaults to the sys¬ 
tem window color. The hbrBackground 
field in the window class ( WNOCLASS) 
structure sets this color at registration 
time. All child controls should allow 
parent windows to modify their color 
scheme. The UM_CTLC0L0R message 
provides a protocol for the parent win¬ 
dow to specify any brush color for any 
child control. 

When the child control processes 
UMJAINT , it sends the m_CTLC0L0R 
message to the parent. The wParam 
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must contain a handle to the display 
context (HDC). The low-order word of l - 
Param must contain a handle to the 
child controls window (HUND). The high- 
order word of IParam contains a CTL 
constant that tells the parent what type 
of control it is. The complete list of CTL 
values for all Windows common con¬ 
trols is shown in Figure 4. Custom con¬ 
trols must define their own values and 
avoid overlapping the predefined 
values. The fader custom control header 
file defines CTLCOLOR_FADER to be 100. 

The return value from the 
WM CTLCOLOR message must be a valid 
brush handle. The SDK documentation 
admonishes that failure to return a 
valid brush handle will place the sys¬ 
tem in an "unstable state." However, 
most applications ignore the 
m_CTLC0L0R and simply let DefWindow- 
Proc() take care of returning the brush 
handle. DefWindowProc () sets the back¬ 
ground color to the system window 
background color and the text color to 
the system window color. With the fader, 
an application could use UM_CTLC0L0R to 
color-code faders, for example. 

Once the colors are properly set, 
PaintFader() begins the actual work of 
rendering the fader control. The Paint- 
Fader() function uses relative coor¬ 
dinate positioning to achieve the most 
scalable results. Even so, the minimum 
useful size for a fader is about 10 pixels 
tall by four pixels wide. The Paint- 
Fader() function draws with left-right 
symmetry along a center line running 
from top to bottom. A fader thumb 
travels up and down a slot drawn 
around the center line. It draws each 
piece in a clockwise fashion to simplify 
maintenance later. 

After the drawing the slot, Paint- 
Fader () paints the ticks. The ticks are 
spaced every three pixels, regardless of 
the fader's actual size. The ticks serve 
no functional purpose other than as a 
visual aid for the user. Conceivably, a 
snap-to-grid mode could be added 
whereby the thumb would only move 
in whole-tick increments. 

Lastly, PaintFader() draws the 
fader thumb. Since the thumb is similar 
to a Windows push-button control, I at¬ 
tempted to reproduce its look as much as 
possible; I chose the UM_BUTT0NFACE color 
for the main interior filled rectangle. 


Listing 2 — Cont’d 

Rectangle(hDC, thumb_rect.left, thumb_rect.top, 
thumb_rect.right, thumb_rect.bottom); 

DeleteObject( SelectObject(hDC.hOldBrush) ); 
if (iThumbHalf > 2) /* Big enough for 3D paint */ 

{ 

DeleteObjectf Select0bject(hDC,h01dPen) ); 
hOldPen ■ SelectObject( hDC, 

CreatePen(PS_SOLIO,1.GetSysColor(C0L0R_WIND0W)) ); 
MoveTofhDC, thumb_rect.left+l, thumb_rect.bottom-1); 
LineTofhDC, thumb_rect.left+l, thumb_rect.top+l); 
LineTofhDC, thumb_rect.right-l, thumb_rect.top+l); 
DeleteObjectf Select0bject(hDC,h01dPen) ); 

hOldPen = SelectObjectf hDC, 

CreatePen(PS_$0UD, 1 .GetSysColor(C0L0R_BTNSHAD0W)) ); 
MoveTofhDC, thumb_rect.right-1, thumb_rect.top+l); 
LineTofhDC, thumb_rect.right-l, thumb_rect.bottom-l); 
LineTofhDC, thumb_rect.left+l, thumb_rect.bottom-1); 

} 

/* restore original pen */ 

DeleteObjectf Select0bject(hDC,h01dPen) ); 

DeleteObjectf SelectObject(hDC.hOldBrush) ); 


EndPaintfhWnd, &ps); 


/* Thumb height is magically l/8th of window height */ 

int GetThumbHeightfint iTotalHeight) 

{ 

return max(iTotalHeight/8, 2); 

) 


/* The fader button is always l/8th the heighth of the window 
and 1/2 the width of the window */ 

void GetFaderThumbRect(HWND hWnd, LPRECT pRc, 

LPRECT pThumbRect, int iLogPos) 

{ 

int x_center; 
int iPhyPos; 
int iThumbHalf; 

LONG ILogRange; 

lLogRange » GetWindowLongfhWnd, FADER_RANGE); 
iThumbHalf = GetThumbHeight(pRc->bottom) / 2; 
iPhyPos = XlatPosLogicalToPhysical(ILogRange, 

pRc->bottom - iThumbHalf, pRc->top + iThumbHalf, 
iLogPos); 

x_center = pRc->right / 2; 
pThumbRect->left * x_center / 2; 

pThumbRect->top = iPhyPos - iThumbHalf; 

pThumbRect->right * (3 * x_center) / 2; 
pThumbRect->bottom * iPhyPos + iThumbHalf; 


/* This "helper" function maps from pixel coordinates to 
logical positions */ 

int XlatPosPhysicalToLogical(LONG ILogRange, int iPhysMax, 
int iPhysMin, int iPhyPos) 

( 

int iLogMin; 
int iLogMax; 
int iResult; 
double dScale; 
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iLogMax = HIW0RD(1LogRange); 
iLogMin ■ L0W0RD(1LogRange); 
dScale * (double)(iPhysMax - iPhyPos) / 

(double)(iPhysMax - iPhysMin); 

iResult « (int) ((double)iLogMin + (iLogMax-iLogMin)*(l-dScale)); 
return iResult; 


/* This "helper" function maps from logical positions to 
physical pixel coordinates */ 

int XlatPosLogicalToPhysical(LONG ILogRange, int iPhysMax, 
int iPhysMin, int iLogPos) 

( 

int iLogMin; 
int iLogMax; 
int iResult; 
double dScale; 

iLogMax ■ HIW0RD(1LogRange); 
iLogMin = L0W0RD(1LogRange); 

dScale * (double)(iLogMax - iLogPos) / 

(double)(iLogMax - iLogMin); 

iResult = (int) ((double)iPhysMin + (iPhysMax-iPhysMin)*(l-dScale)); 
return iResult; 


/* The "caret" is a way of highlighting the controls which are 
active and inactive. Note that a ones-complement is used so we 
don't need to know the previous state */ 

void DrawCaret(HDC hDC, LPRECT Iprc) 

( 

HBRUSH hOldBrush; 
int iWidth; 
int iHeight; 

if (lprc->bottom - lprc->top < 4) 
return; 

/* initialize display context */ 
hOldBrush = (HBRUSH)SelectObject( hDC, 

GetStockObject(GRAY_BRUSH) ); 

/* draw caret */ 

iWidth = lprc->right - lprc->left; 
iHeight = lprc->bottom - lprc->top; 

PatBlt( hDC, lprc->left+l, lprc->top+l, iWidth-2, 3, PATINVERT ); 
PatBltf hDC, lprc->right-4, lprc->top+l, 3, iHeight-2, PATINVERT ); 
PatBlt( hDC, lprc->left+l, 1prc->bottom-4, iWidth-2, 3, PATINVERT ); 
PatBlt( hDC, lprc->left+l, lprc->top+l, 3, iHeight-2, PATINVERT ); 

/* restore display context */ 

SelectObject( hDC, hOldBrush ); 


/* End of File */ 


The fader thumb is always scaled to 
be 1 /8th as tall as the window and 1/2 
the width of the window. If the fader 
thumb is six or more pixels tall (i- 
ThumbHalf > 2), then it will be 
rendered with 3-D button shadowing 
effects. According to Welch (1990), the 
3-D effect should be produced by 
rendering the top and left edges with a 
solid brush based on the COLOR_UINDOU 
system color. Similarly, the bottom and 
right edges should be colored with a 
solid brush based on the 
C0L0R_BTNSHAD0U system color. Al¬ 
though you may try other color com¬ 
binations, only this trio is guaranteed to 
work correctly on both color and 
monochrome systems. 

The only messages other than 
UM_PAINT that require the child control 
to draw are the UM_SETFOCUS and 
m_KILLFOCUS messages. The UM_SET- 
FOCUS message occurs when a child 
window is eligible for keyboard input. 
Similarly, the UM_KILLFOCUS message 
appears when a child window is no 
longer the focus of input. Child controls 
that accept input should provide some 
display mechanism for indicating focus. 
This is especially necessary when your 
control expects keyboard input. Child 
controls typically indicate they have the 
input focus by drawing a thin gray rec¬ 
tangle in the control. 

The fader window function handles 
both WM_SETF0CUS and UM_KILLFOCUS in 
the same case statement. To simplify 
coding, these messages both invoke the 
DrawCaretf) function. The DrawCaretf) 
function inverts a portion of the fader 
thumb area. Since PatBltf) does a 
straight binary NOT operation, the 
second time it is called it will simply 
undo what it did the first time. This en¬ 
sures that things stay in sync because a 
WM_SETFOCUS message is always fol¬ 
lowed by a UM KILLFOCUS before 
another UM_SETFOCUS arrives. 

To Be Continued 

Listing 1 contains the header file for 
the custom control and Listing 2 con¬ 
tains most of the code that implements 
the control. Next month, I will conclude 
by explaining and adding all the func¬ 
tions necessary to make a custom con¬ 
trol interact properly with dialog box 
editors. The article will also include a pro¬ 
gram to demonstrate the fader control. □ 
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A Font Previewer 


Doug Overmyer 


Adobe Type Manager (ATM) has been a wonderful boon to Windows users in 
almost every way. Before ATM we made do with four or five typefaces, now we 
choose from 30 or more - too many, in fact, to easily remember each one's 
style and appearance. To further complicate things, each has a slightly different 
name, an unavoidable fact of life where the name of a typeface may be a 
valuable, copyrighted property. This confusion of font names and styles was the 
idea behind Font Preview, a utility designed to provide an on-screen preview of 
typefaces that could work along with word processing and publishing programs. 

The point was to eliminate having to remember what each 
typeface looked like and let the designer concentrate on getting 
the one that looked the way it should. (Source code for Font 
Preview is provided in Listings 1, 2, and 3.) 

The solution to this problem involved several tradeoffs. One 
option was to create a scrollable window and draw a sample of 
each available typeface in the window, one face per line, as in 
the font utility control panel. Unfortunately, this process bogs 
down very quickly, and turns out to be unacceptable with even 
a moderate number of typefaces. Another possibility was to 
draw a single face at a time and let the user quickly switch 
between faces. That's the strategy adopted in Font Preview: a 
list box control on the left side of the main window with the 
available typeface names, and a child window on the right dis¬ 
playing the typeface sample. 


Doug Overmyer has a Ph.D. from Princeton University in 
Renaissance/Reformation history. He has worked for the federal 
government as an applications programmer for ten years. He 
lives with his wife, Elizabeth, in the San Francisco Bay area. You 
can contact Doug on CompuServe at 71021, 2535. 
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Listing 1 (preview.pas) 

(Font Preview - 1.5 Program Copyright (C) Doug Overmyer 7/26/91} 
program FontPreview; 

{$S-} ($R PREVIEW.RES}{$R-} 

uses WinTypes, WinProcs, WinDos, Strings, WObjects.StdDlgs,Fonts,Buttons; 
const 


id Butl 

= 201; 

{Ownerdraw Button 1 } 

id_But2 

= 202; 

{ " 2 } 

id_But3 

= 203; 

{ " 3 } 

id_But4 

= 204; 

{ " 4 } 

id But5 

= 205; 

{ 5 } 

id DlLbl 

= 301; 

{List box in Dlgl } 

id~Stl 

= 401; 

{Static text 1 } 

id“st 2 

= 402; 

{Static text 2 } 

id“St3 

= 403; 

{Static text 3 } 

id~St4 

= 404; 

{Static text 4 } 

id D3Setup 

= 501; 

{Setup button in Dlg3} 

id D3EC1 

= 506; 

{Edit control in Dlg3} 

id~D30K 

= 521; 

{OK button in Dlg3 } 

idjb2 

= 601; 

{FBox list box control} 

idm_About 

= 801; 

{menu id for PV_About menu} 

idm_RunCP 

= 802; 

{menu id for run control panel 

idm_RunATM 

= 803; 

{menu id for run ATM } 


type 

TPVApplication = object(TApplication) 
procedure InitMainWindow;virtual; 

end; 

PPVDlgl = A TPVDlgl; {Font Sizes Dialog} 

TPVDlgl = object(TDialog) 

FontSize: Integer; 

procedure WMInitDialog(var Msg:TMessage);virtual wm_First+wm_InitDialog; 
procedure IDDlLBl(var Msg:TMessage)'.virtual id_First+id_DlLbl; 
end; 

PPVD1g2 = A TPVDlg2; {String Dialog} 

TPVD1g2 = object(TDialog) 

DCType:Char; 

procedure WMInitDialog(var Msg:TMessage);virtual wm_First+wm_InitDialog; 

end; 


The rest of the features are designed 
to support these main interface ele¬ 
ments, or to exploit them easily to pro¬ 
vide an added function or two. The 
sample text defaults to the name of the 
typeface, but it's easy to let users cre¬ 
ate their own text. To allow for 
specification of font size, a dialog box 
displays a list of font sizes correspond¬ 
ing either to available printer sizes or, 
for scalable fonts, to a range of sizes. 
Since creating the font size dialog box 
entails gathering quite a bit of informa¬ 
tion about each typeface available, 
another option allows the information 
to be displayed as font metrics in a 
couple of dialog boxes for handy refer¬ 
ence. 

To implement these features Font 
Preview must accomplish several tasks. 
In addition to the usual Windows over¬ 
head of maintaining windows, respond¬ 
ing to messages, managing memory, 
and so forth, Font Preview pursues this 
general scheme: 

• Build interface elements: the main 
window, the font list child control, 
the text preview child window, the 


Liana 

Interpretive C-like 
Object-Oriented Programming 
Language and Class Library 
for Windows 3 
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□ Faster and less error-prone coding 

□ Automatic memory management 

□ Simplified string manipulation 

□ Flexibility of an interpreter 

□ Better run-time error detection 

□ High level class library 
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Listing 1 — Cont’d 

type {Child win to display sample text} 

PFontWindow = A TFontWindow; 

TFontWindow = object(TWindow) 

FontHeight: Longlnt; 

constructor Init(AParent: PWindowsObject; ATitle: PChar); 
procedure Paint(PaintDC: HOC; var Paintlnfo: TPaintStruct); virtual; 
end; 

type {MainWindow of Application} 

PPVWindow = A TPVWindow; 

TPVWindow = object(TWindow) 

FWin:PFontWindow; {child window displaying typeface sample} 

FBox:PListBox; {List box of available type faces} 

Fonts:PFonts; 

LogPixY:Integer; 

Bn1,Bn2,Bn3,Bn4,Bn5:PODButton; 

Dlgl : PPVDlgl; {Select font size dialog} 

Stl,St2,St3,St4:PStatic; 

TextString:Array[0..80] of Char; (to display in FWin} 

FontSelection:Integer; {Index into Fonts } 

FontSize:Integer; {Current font size } 

constructor Init(AParent:PWindowsObject;ATitle:PChar); 
destructor Done;virtual; 
procedure SetupWindow;virtual; 

procedure Paint(PaintDC:HDC;var PaintlnforTPaintStruct)jvirtual; 
procedure LoadFBox; 

procedure WMDrawItem(var Msg:TMessage);virtual wm_First + wm_DrawItem; 

procedure WMSize(var Msg:TMessage);virtual wm_First+wm_Size; 
procedure WMSetFocus(var Msg:TMessage)jvirtual wm_First+wm SetFocus; 
procedure IDButl(var Msg:TMessage)jvirtual id_First+id_Butl; {Information} 
procedure IDBut2(var Msg:TMessage);virtual id_First+id_But2; {Size} 
procedure IDBut3(var Msg:TMessage)jvirtual id_First+id_But3; {String} 
procedure IDBut4(var Msg:TMessage);virtuaT id_First+id_But4; {Text Metrics} 

procedure IDBut5(var Msg:TMessage)jvirtual id_First+id_But5; {Exit} 
procedure IDLB2(var Msg:TMessage)jvirtual id_First+id_lb2; 

procedure EnumerateFontsjvirtual; 

procedure WMSysCommand(var Msg:TMessage);virtual wm_First+wm_SysCommand; 

function GetIC:HDC;virtual; 
end; 

|*************************** q ] o b a 1 s **************************} 
var 

MainWin:PPVWindow; 

|*************************** Methods *************************} 

procedure TPVApplication.InitMainWindow; 

begin 

MainWindow := New(PPVWindow,Init(nil,'Font Preview')); 

MainWin := PPVWindow(MainWindow); 
end; 

|************************** TPVWindow ******************************J 
constructor TPVWindow.Init(AParent:PWindowsObject;ATitle:PChar); 
begin 

TWindow.Init(AParent,ATitle); 

Attr.X := 20; Attr.Y := 25; Attr.W := 595; Attr.H := 260; 

Bnl := New(PODButton,Init(@Self,id_Butl,'About',0,0,50,50,False,'PV_Bn1')); 

Bn2 := New(P0DButton,Init(@Self,id_But2,'Font Size',50,0,50,50,False,'PV_Bn2')); 

Bn3 := New(P0DButton,Init(@Self,id_But3,'String',100,0,100,50,False,'PV_Bn3')); 

Bn4 := New(P0DButton,Init(@Self,id_But4,'TM',200,0,50,50,False,'PV_Bn4')); 

Bn5 := New(P0DButton,Init(@Self,id_But5,'Exit',250,0,50,50,False,'PV Bn5')); 

Stl ;= New(PStatic,Init(@Self,id_Stl,'',315,5,240,18,75)); 

St2 := New(PStatic,Init(@Self,id St2, " ,315,26,240,18,75)); 

St3 := New(PStatic,Init(@Self,id_ST3,'',310,3,250,44,75)); 

St4 := New(PStatic,Init(@Self,id_St4, ".5,55,100,18,75)); 

St2 A .Attr.Style := St2 A .Attr.Style or ss_LeftNoWordWrap; 

St3 A .Attr.Style := St3 A .Attr.Style or ss_BlackFrame; 

St4 A .Attr.Style := St4 A .Attr.Style or ss_Left; 

FontSelection := 0; 

FontSize := 48; 

StrCopy(TextString,''); 

Fonts := New(PFonts.Init); 

EnumerateFonts; 

FWin := New(PFontWindow,Init(@Self,ATitle)); 

With FWin A .Attr do Style := Style or ws Child or ws HScroll or ws VScroll or ws_Border ; 
FBox := New(PListBox,Init(@Self,id_lb2,0,0,0,0)); 

With FBox A .Attr do Style := Style and not lbs_Sort; 
end; 

procedure TPVWindow.SetupWindow; 
begin 

TWindow.SetupWindow; 

SetClassWord(HWindow,GCW_HIcon,LoadIcon(HInstance,'PV_Icon')); 
AppendMenu(GetSystemMenu(hWindow,false),MF_Separator,0,ni1); 

AppendMenu(GetSystemMenu(hWindow,false),0,idm_RunCP,'Run Control Panel'); 
AppendMenu(GetSystemMenu(hWindow,false),0,idm RunATM,'Run ATM'); 
AppendMenu(GetSystemMenu(hWindow,false),MF_Separator,0,ni1); 

AppendMenu(GetSystemMenu(hWindow,false),0,idm_About,'About...'); 

LoadFBox; 

end; 
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Listing 1 — Cont’d 


procedure TPVWindow.Paint(PaintDC:HDC;var PaintlnforTPaintStruct); 
var 

ThePen,01dPen:HPen; 

TheBrush,01dBrush:HBrush; 

begin 

TheBrush :* 6etStock0bject(LtGray_Brush); 

ThePen :* CreatePen(ps_Solid,l,$00000000); 

OldPen := SelectObject(PaintOC,ThePen); 

OldBrush Select0bject(Pa1ntDC,TheBrush); 

Rectangle(Pa1ntDC,0,0,1024,50); 

SelectObject(PaintDC,OldBrush); 

SelectObject(PalntDC.OldPen); 

DeleteObject(ThePen); 
end; 

procedure TPVWindow.WMDrawItem(var Msg:TMessage); 

var 

PDIS : A TDrawItemStruct; 
begin 

PDIS := Pointer(Msg.lParam); 
case PDIS A .CtlType of 
odt_Button: 

case PDIS A .Ct1ID of 
id_Butl :Bnl A .DrawItem(Msg); 

id_But2 :Bn2 A .Drawltem(Msg); 
id_But3 :Bn3 A .DrawItem(Msg); 
id But4 :Bn4 A .DrawItem(Msg); 
id_But5 :Bn5 A .Drawltem(Msg); 

end; 

end; 

end; 

destructor TPVWindow.Done; 
begin 

Dispose(BNl.Done);Dispose(Bn2,Done);Dispose(Bn3,Done); 

Dispose(Bn4,Done);Dispose(Bn5,Done);Dispose(Stl,done); 

Dispose(St2,Done);Dispose(St3,Done);Dispose(St4,Done); 

TWindow.Done; 

end; 

procedure TPVWindow.WMSize(var Msg:THessage); 
begin 

SetWindowPos(FBox A .HWindow,0,-l,75,(Msg.LParamLo div 3)+l, 

((Msg.LParamHi-70) ),swp_NoZ0rder); 

SetWindowPos(FWin A .HWindow,0,(Msg.LParamLo div 3)-l,49, 

(Msg.LParamLo * 2 div 3)+l,(Msg.LParamHi-48),swp_NoZOrder); 

end; 

procedure TPVWindow.WMSetFocus(var MsgrTMessage); 
begin 

SetFocus(FBox A .HWindow); 

end; 

procedure TPVWindow.IDButl(var Msg:TMessage); 
begin 

Appl ication''. ExecDi al og(New(PDialog, Ini t(@Sel f,' PV_About'))); 

end; 

procedure TPVWindow.IDBut2(var MsgrTMessage); 
begin 

Dlgl :* new(PPVDlgl,Init(GSelf,'PV_Dlgl')); 

Appl i cat ion''. ExecDi alog(Dlgl); 

if (Dlgl A .FontSize) <> 0 then InvalidateRect(Fwin / \HWindow,ni1.True); 
end; 

procedure TPVWindow.IDBut3(var MsgrTMessage); 
begin 

If Application^.ExecDialog(New(PInputdialog,Init(@Self,'Font String', 

'Enter text:',Textstring,SizeOf(Textstring)))) <> 1 then StrCopy(Textstring, "); 
Inval idateRect(FWin / \HWindow,nil .True); 
end; 

procedure TPVWindow.IDBut4(var MsgrTMessage); 
var 

Dig : PPVDlg2; 
begin 

Dig :=New(PPVDlg2,Init(@Self,'PV_Dlg2')); 

Dlg A .DCType := 'S'; 

Application^.ExecDialog(Dig); 

Dig :=New(PPVDlg2,Init(@Self,'PV_Dlg2')); 

Dlg A .DCType := 'P'; 

Application A .ExecDialog(Dlg); 

end; 


custom icon bar, and static text con¬ 
trols 

• Enumerate available fonts and font 
sizes, and store them in a memory 
structure for quick retrieval 

• Load the font list box 

• Redraw the preview window 

• Display the quick info lines in static 
text boxes 

• Respond to menu/icon bar choices 
and keep things in sync 

Turbo Pascal for windows has 
several features that can ease these 
tasks. The Pascal compiler manages 
memory in an almost invisible fashion - 
to such an extent that constructing a 
1/2 or 2 MB memory object is no big 
deal. The ObjectWindows class libraries 
take over some of the drudgery of con¬ 
structing the visual elements and pro¬ 
vide an extensible structure to build on. 
Finally, the Collections class object 
makes it easy to build arrays of just 
about anything - and these arrays are 
smart enough to grow in size if they 
need to! Let's look at how Font Preview 
uses these capabilities to solve several 
aspects of the general program scheme 
described above. 

Enumerating Fonts 

The Windows function EnumFonts 
provides a comprehensive, although con¬ 
voluted, way to obtain font information 
about any particular device context. It 
requires a call-back function, Font- 
Func(), which is passed two font infor¬ 
mation structures, a FontType field and 
a user data field. If face name is nil, the 
callback function is called once for each 
facename known to the device context; 
if facename is supplied, it is called once 
for each size of the specified facename. 
To enumerate all the faces and the 
sizes for each face, you need to set up 
two calls to EnumFonts: the first to ob¬ 
tain the typeface names, and the 
second to get the sizes for each face. In 
short, the font manager of GDI has quite 
a bit to say when asked “Who's home?" 
and that information will have to be 
stored somewhere in memory for quick 
access later on. 

The ObjectWindows Library (OWL) T- 
Collection class seems ready-made for 
handling this situation. It lets you 
store up to 16,000 pointers to any 
objects you wish, and then access 
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Listing 1 — Cont'd 

procedure TPVWindow.IDBut5(var Msg:TMessage); 
begin 

CloseWindow; 

end; 

procedure TPVWindow.LoadFBox; 
var 

Indx : Integer; 

Font : PFontltem; 

Bufl :Array[0..20] of Char; 

Buf2 :Array[0..5] of Char; 
begin 

Str(Fonts 7 '.Count,Buf2); 

StrECopy(StrECopy(StrECopy(Bufl,'*'),Buf2),' Type Faces*'); 
St4~.SetText(Bufl); 
for indx : s 0 to (Fonts 7 '.Count -1) do 

FBox 7 '. InsertStri ng (PFontI tem(Fonts 7 '. At (Indx) )*. LogFont. 1 f FaceName, -1); 

end; 

procedure TPVWindow.IDLB2(var Msg:TMessage); 
var 

Indx:Integer; 
begin 

case Msg.lParamHi of 
lbnDblClk, lbn_SelChange: 
begin 

Indx := FBox 7 '.GetSel Index; 

FontSelection := Indx; 

Inval idateRect(FWin 7 '.HWindow,ni1 .True); 
end; 
end; 
end; 

procedure TPVWindow.EnumerateFonts; 
var 

IC :HDC; 
begin 

IC := GetIC; 

Fonts 7 '. Enumerate(IC); 

DeleteDC(IC); 
end; 

procedure TPVWindow.WMSysCommand(var Msg:TMessage); 

begin 

case Msg.Wparam of 

idm_About:Application^.ExecDialog(New(PDialog.init(@Self,'PV_About'))); 
idm_RunCP: 

begin 

WinExec('Control',1); 

Fonts 7 '.Relnit; 

EnumerateFonts; 

end; 

idm_RunATM: 

WinExec('ATMCNTRL'.l); 

else 

DefWndProc(Hsg); 

end; 

end; 

function TPVWindow.GetIC:HDC; 

function StrTok(P:PChar;C:Char):PChar; 
const 

Next:Pchar = nil; 
begin 

if P = NIL then P := Next; 

Next : b StrScan(P.C); 

If Next <> NIL then 
begin 

Next 7 ' := #0; 

Next :« Next+1; 
end; 

StrTok := P; 
end; 
var 

Bufl :Array[0..80] of Char; 

DeviceName:Array[0..79] of Char; (win.ini device= } 

DriverName:Array[0..79] of Char; 

OutPort:Array[0..79] of Char; 
begin 

GetProfileString('Windows','device',',,'.Bufl.SizeOf(Bufl)); 

StrCopy(DeviceName,StrTok(Bufl,',')); 

StrCopy(DriverName,StrTok(nil,',')); 

Strcopy(OutPort,StrTok(nil,',')); 

GetIC : = CreateIC(DriverName.DeviceName,OutPort,ni1); 
end; 
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Listing 1 — Cont’d 

|************************** jpontWindow ************************j 
constructor TFontWindow.Init(AParent: PWindowsObject; ATitle: PChar); 
begi n 

TWindow.Init(AParent, ATitle); 

Attr.Style := Attr.Style or ws_VScroll or ws_HScroll or ws_Border; 
FontHeight :■ 0; 

Scroller := New(PScroller, Init(@Self, 12, 12,0,0)); 
end; 

procedure TFontWindow.Paint(PaintDC: HDC; var Paintlnfo: TPaintStruct); 
var 

VPosition: Integer; 

Fontltem :PFontItem; 

AFont,01dFont:HFont; 

Extent:LongRec; 

Text:Array[0..80] of Char; 

Buf:Array[0..80] of Char; 

FH:Real; 

szFH:Array[0..5] of Char; 

LPY:Integer; 

FontMetrics:TTextMetric; 

begin (build text display) 

LPY := GetDeviceCaps(PaintDC,LogPixelsY); 

Fontltem : = MainWin A .Fonts A .At(MainWin A .FontSelection); 

FontHeight :* MainWin A .FontSize * LPY div 72; 
FontltenT.LogFont.lfHeight : = FontHeight; 

FontItem A .LogFont.lfWidth :- 0; 

FontItem A .LogFont.lfWeight := 0; 

Fontltem''.LogFont.lfQuality : = Proof_Quality; 

VPosition := 5; 

if StrComp(MainWin A .Textstring,* 1 ) * 0 then 
StrCopy(Text,FontItem A .LogFont.lfFaceName) 
else 

StrCopy(Text,MainWin A .Textstring); 

AFont :■ CreateFontlndirect(Fontltenr.LogFont); 

OldFont :* SelectObjectfPaintDC, AFont); 

GetTextMetrics(PaintDC,FontMetri cs); 

Longlnt(Extent) :■ GetTextExtent(PaintDC,Text,StrLen(Text)); 
Scroller A .SetRange(Extent.lo div 12, Extent.Hi div 12); 
Text0ut(PaintDC, 10,VPosition, Text.StrLen(Text)); 

StrCopy(Buf,'Face: '); 

MainWin A .$tl A .$etText($trCat(Buf,FontItem A .LogFont.lfFaceName)); 

FH :-(FontMetrics.tmHeight)*72 / LPY; 

Str(FH:5:l,szFH); 

StrECopy(StrECopy(Buf,'Actual :'),szFH); 
if FontItem A .FontType and Raster_FontType « 0 then 

StrCatfBuf,' Type:Vector,') else StrCat(Buf,' Type:Raster,'); 
if FontItem A .FontType and Device_FontType » 0 then 
StrCatfBuf,'GDI') else StrCat(Buf,'Device'); 
MainWin A .St2 A .SetText(Buf); 

SelectObjectfPaintDC,OldFont); 

DeleteObject(AFont); 
end; 

procedure TPVDlgl.IDD1LB1(var Msg:TMessage); 
var 

Buf:Array[0..5] of Char; 

Ptr : PChar; 

Idx.ErrCode:Integer; 
begi n 

case Msg.lParamHi of 
1bn_SelChange,1bn_Dbl Cl k: 
begin 

Ptr :• Buf; 

Idx := SendDlgltemMsg(id_DlLbl,lb_GetCurSel ,0,0); 
SendDlgItemMsg(id_DlLbl,lb_GetText,word(Idx),LongInt(Ptr)); 
val(Ptr,FontSize,ErrCode); 

MainWin A .FontSize :* FontSize; 
end; 
end; 
end; 

procedure TPVDlgl.WMInitDialogfvar Msg:TMessage); 
var 

pTextItem:PChar; 

Buf:Array[0..5] of Char; 

Indx,Indx2:Integer; 

DSN.ErrCode :Integer; 

Font1 tern:PFontItern; 

LPY : Integer; 

Height:Integer; 


them systematically. So, you first 
define an object that contains the data 
you want to save for each typeface, 
and then you store a number of them 
in a collection, one for each face. Finally, 
since this is an OWL program, put the 
whole process in a new class so that 
you don't have to agonize over it every 
time you want to enumerate fonts. The 
object that holds the enumeration data 
looks like this: 

type 

PFontltem = ''TFontltem; 

TFontltem = object(TObject) 
LogFont:TLogFont; 

FontType:Integer; 
Sizes:PCollection; 
constructor Init(NewItem 

TLogFont;NewType:Integer); 
destructor Done;virtual; 
end; 

Each TFontltem contains a TLog- 
Font record supplied by GDI, a Font- 
Type field, and a Sizes collection. Sizes 
will collect integer values which hold 
the available font sizes in device units. 
Just to confuse the issue, EnumFontsO 
returns the available sizes only for bit¬ 
mapped fonts - scalable fonts return a 
single size - so it’s also necessary to 
save the FontType flag to be able to 
determine later the type of font you 
are dealing with. 

The class dynamically allocates 
space for these objects on the heap 
and stores a pointer to the objects in 
the following collection: 


PFontCollection = A TFontCollection; 

TFontCollection » object(TSortedCollection) 

function KeyOf(Item:Pointer):Pointer[virtual; 
function Conpare(Keyl,Key2:Pointer):Integer;virtual; 
function GetCount:Integer;virtual; 


Notice that TFontCollection is de¬ 
scended from TSortedCollection. The 
KeyOf and Compare methods define a 
sort sequence based on the Log- 
Font'IfFaceName field. The result is a 
collection of TFontltem objects sorted 
by facename. Why not store the other 
font information structure returned by 
EnumFonts - the TTextMetric record? 
Well, it isn't required for this task since 
the T Log Font record provides all the data 
needed for asking Windows to create a 
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real font. Also, it turns out that you 
need to check up on what the font 
manager has actually done after it has 
realized a font for you. Therefore, Font 
Preview calls GetTextmetrics after 
realizing a logical font and ignores the 
TTextMetrics returned by EnumFonts. 

The code to actually enumerate the 
fonts, consisting of functions 
EnumerateFace and EnumerateSize and 
procedure TFonts.Enumerate, is shown 
in Listing 2. The program first gets a DC 
for the printer, then creates the proce¬ 
dure variable EnumProc and sets it to 
point at EnumerateFace. It then calls 
the API function EnumFonts() along 
with a null parameter for facename and 
EnumProc for the call-back function. In 
turn, Windows calls EnumerateFace 
once for each typeface, passing along 
the TLogFont record and FontType field. 
We create a new dynamic object (P- 
Fontltem) on the heap and store a 
pointer referent in the Faces collection. 
Faces sorts the new object based on 
the Faces''. LogFont''.I fFaceName field, 
and replaces duplicate facenames with 
the new entry. 


Listing 1 — Cont’d 


begi n 

TDialog.WHInitDialog(Msg); 

Fontltem := MainW.in*.Fonts*.At(MainWin*.FontSelection); 

Indx := 12; Indx2 :> 0; 
pTextltem := Buf; 

If (Fontltem*.FontType and Raster_FontType) ■ 0 then (0 * vector font) 
begi n 

Str(Indx:3,Buf); 
while Indx < 200 do 
begin 

SendD1gItemMsg(id_DlLbl,lb_AddString,word(0).Longlnt(pTextltem)); 
Inc(Indx,12); 

$tr(Indx:3,Buf); 

end; 
end 
el se 

for Indx2 := 0 to Fontltem*.Sizes*.Count-1 do 
begin 

Height := PIntObj(Fontltem*.Sizes*.At(Indx2))*.Int; 

Str(Height * 72 div MainWin*.Fonts*.LogPixY:3,Buf); 

SendDlgItemMsg(id_01Lbl,lb_AddStn'ng,word(0).Longlnt(pTextltem)); 
end; 

end; 


|*************************** TPVD1g2 ***************************| 

procedure TPV01g2.WMInitDialog(var Msg;TMessage); 

const 

FontFamily : ArrayfO..5,0..11] of Char * ('Don''t Care', ' Roman', 
' Swiss',' Modern', ' Script', 'Decorative'); 


var 


FontItem:PFontItem; 

TextItem:PChar; 

Buf:Array[0..3] of Char; 
Buf60:Array[0..60] of Char; 
FontMetrics:TTextMetric; 

IC:HOC; 

01dFont,NewFont:hFont; 

LogFont:TLogFont; 
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Listing 1 — Cont’d 


DeviceName:Array[0..30] of Char; 

ScreenDC:hDC; 
begin 

Fontltem := MainWin A .Fonts A .At(MainWin A .FontSelection); 
if DCType = *P' then 
begin 

IC MainWin A .GetIC; 

StrCopy(DeviceName,'Printer'); 

Font I tern''. LogFont. 1 f Height ;■ MainWin A .FontSize * 

GetDeviceCaps(IC.LogPixelsY) div 72; 

FontItem A .LogFont.lfQuality := Proof_Quality; 

Fontltem^.LogFont.lfWeight : = fw_Normal; 

NewFont := CreateFontlndirect(FontItenr A .LogFont); 

OldFont := SelectObject(IC,NewFont); 

GetTextMetrics(IC,FontMetrics); 

SelectObject(IC,OldFont); 

DeleteObject(NewFont); 

DeleteDC(IC); 
end 
else 
begin 

StrCopy(DeviceName,'Screen Display'); 

ScreenDC :=GetDC(MainWin A .HWindow); 

FontltenT.LogFont.lfHeight := MainWin A .FontSize * 

GetDeviceCaps(ScreenDC,LogPixelsY) div 72; 

FontItem A .LogFont.lfQuality :* Proof_Quality; 

FontltenT.LogFont.1fWeight := fw_Normal; 

NewFont := CreateFontlndirect(FontltenT.LogFont); 

OldFont : s SelectObject(ScreenDC,Newfont); 

GetTextMetrics(ScreenDC,FontMetrics); 

SelectObject(ScreenDC,OldFont); 

DeleteObject(NewFont); 

ReleaseDC(MainWin A .HWindow,ScreenDC); 
end; 

TDialog.WMInitDialog(Msg); 

StrECopy(StrECopy(StrECopy(Buf60,FontItenT.LogFont.lfFaceName),' - ').DeviceName); 
SetDlgltemText(HWindow,601,Buf60); 

Str(FontMetrics.tmHeight:3,Buf); SetDlgItemText(HWindow,612,Buf); 
Str(FontMetrics.tmAscent:3,Buf); SetDlgItemText(HWindow,613,Buf); 
Str(FontMetrics.tmDescent:3,Buf); SetDlgItemText(HWindow,614,Buf); 

Str(FontMetrics.tmlnternalLeading:3,Buf); SetDlgltemText(HWindow,615,Buf); 

Str(FontMetrics.tmExternalLeading:3,Buf); SetDlgltemText(HWindow,616,Buf); 
Str(FontMetrics.tmAveCharWidth:3,Buf); SetDlgItemText(HWindow,617,Buf); 
Str(FontMetrics.tmMaxCharWidth:3,Buf); SetDlgltemText(HWindow,618,Buf); 
Str(FontMetrics.tmWeight:3,Buf); SetDlgItemText(HWindow,619,Buf); 

Str(FontMetrics.tmltalic:3,Buf); SetDlgltemText(HWindow,620,Buf); 

Str(FontMetrics.tmllnderl i ned:3,Buf); SetDlgItemText(HWi ndow,621,Buf); 

Str(FontMetrics.tmStruckOut:3,Buf); SetDlgltemText(HWindow,632,Buf); 
Str(FontMetrics.tmFirstChar:3,Buf); SetDlgltemText(HWindow,633,Buf); 
Str(FontMetrics.tmLastChar:3,Buf); SetDlgItemText(HWindow,634,Buf); 
Str(FontMetrics.tmDefaultChar:3,Buf); SetDlgltemText(HWindow,635,Buf); 
if FontMetrics.tmPitchandFamily and 1 > 0 then SetDlgItemText(HWindow,636,'Variable') 
else SetDlgItemText(HWindow,636,'Fixed'); 
SetDlgItemText(HWindow,637,FontFamily[FontMetrics.tmPitchAndFamily shr 4] ); 
if FontMetrics.tmCharSet = ANSI_CharSet then SetDlgItemText(HWindow,638,'Ansi') 
else if FontMetrics.tmCharSet = 0EM_CharSet then SetDlgItemText(HWindow,638,'OEM') 
else if FontMetrics.tmCharSet = Symbol_CharSet then SetDlgItemText(H- 
Window,638,'Symbol') 

else if FontMetrics.tmCharSet = ShiftJis_CharSet then SetDlgItemText(H- 
Window,638,'ShiftJis') 

else SetDlgItemText(HWindow,638,' '); 

Str(FontMetrics.tmOverHang:3,Buf); SetDlgItemText(HWindow,639,Buf); 
Str(FontMetrics.tmDigitizedAspectX:3,Buf); SetDlgltemText(HWindow,640,Buf); 

Str(FontMetrics.tmDigitizedAspectY:3,Buf); SetDlgltemText(HWindow,641,Buf); 
end; 

{*********************** TPVApplication **************************j 

var 

PVApp : TPVApplication; 
begin 

PVApp.Init('Font Preview'); 

PVApp.Run; 

PVApp.Done; 
end. 

{ End of File } 


The font sizes are enumerated in a 
similar fashion. The major difference is 
that a Sizes collection for each 
typeface already exists as part of its P- 
Fontltem instance. The task is to popu¬ 
late this integer collection with avail¬ 
able font sizes. The call-back function 
EnumerateSize takes each font size and 
stores it in the Faces*.Sizes collec¬ 
tion using the index provided by the 
user data field Indx. Sizes is quite effi¬ 
cient - from a minimal collection allo¬ 
cated to begin with, it can grow if need 
be to accommodate fonts with many 
sizes. 

Listing 2 also defines a PFonts class 
to put an object envelop on this whole 
affair and seal off the code. This class 
consists of two variables to hold the 
resolution of the enumerated fonts and 
several functions for managing access 
to the font data. The program has only 
to create a variable of type PFonts, ini¬ 
tialize it, and call the Enumerate 
method with a suitable hDC. The pro¬ 
gram uses the At and Count methods 
several times to retrieve font records, 
iterate over the collection, and general¬ 
ly keep things on track. The Ma inUindow 
maintains an instance variable, Font- 
Selection, which provides an index 
into the Fonts collection for use with 
the Fonts*.At () method. At several 
points the program retrieves the cur¬ 
rent typeface using the At method and 
iterates over the subcollections pointed 
to by Faces*. Sizes. 

The Fonts unit (Listing 2) can now 
take over the task of managing font 
enumeration for the program. The P- 
Fonts class effectively hides the details 
of font enumeration - it creates the 
complex objects to hold font enumera¬ 
tion data, manages the objects without 
much intervention, and serves up logi¬ 
cal font records on demand. And all of 
this is stored conveniently on the global 
heap by the TPW memory manager, 
which handles all the locking and un¬ 
locking of memory seamlessly. 

The Icon Bar 

Not only are icon bars fashionable 
these days, but they also make sense 
for a program like Font Preview, which 
has only a few user choices. Rather 
than looking like a Los Angeles freeway 
sign, the icon bar gets by with five icons 
that trigger all the program functions. 
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Unfortunately, Windows has no built-in 
support for icon bars, so it's necessary 
to do it by hand, making the process as 
simple as possible. ObjectWindows and 
inheritance are a great help here. 

Actually, Windows has an object 
that almost does the job - the ubiqui¬ 
tous button control. These buttons can 
have an "owner-draw” button style that 
provides the functionality of a button 
control but leaves the appearance up to 
the program. Put a few of these side by 
side and you have an icon bar. The 
hard part is handling the repainting of 
the button and maintaining a “button- 
like” appearance. So that these buttons 
can be used in other programs, a 
general solution seems desirable. 

Font Preview defines a TODButton 
object (Listing 3) that behaves rather 
like a regular button control. 

This object is descended from the T- 
Button type, but adds a few charac¬ 
teristics of its own. Its style is set to 
bs_ownerdraw in the Init method, and 
it adds an instance variable, HBmp, to 
store a bitmap for the face of the but¬ 
ton and a State field to help remember 
if the button is pressed in or out. The 


Listing 2 (fonts.pas) 


(FONTS - Extensions to ObjectWindows Copyright (C) Doug Overmyer 10/1/91} 

unit Fonts; 

interface 

uses WinTypes, WinProcs, WinDos, Strings, WObjects.StdDlgs; 
type 

PIntObj = A TInt0bj; 

TIntObj = object(TObject) 

Int:Integer; 

constructor lnit(NewInt:Integer); 
destructor Done;virtual; 
end; 

type 

PFontltem « A TFontItem; 

TFontltem = object(TObject) 

LogFont:TLogFont; 

FontType:Integer; 

Sizes:PCollection; 

constructor Init(NewItem:TLogFont;NewType:Integer); 
destructor Done;virtual; 
end; 

PFontCollection = A TFontCollection; 

TFontCollection = object(TSortedCollection) 

function KeyOf(Item:Pointer):Pointer;virtual; 
function Compare(Keyl,Key2:Pointer):Integer;virtual; 
function GetCount:Integer;virtual; 
end; 
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constructor Init requires only one 
added piece of information over the 
regular TButton.Init - the name of the 
bitmap resource to draw on the face. 
The implementation of Init is easy - it 
calls the ancestor method, T- 
Button. Init, modifies the style field to 
include bs_ownerdraw, loads the HBmp, 
and initializes the State field. These 
few lines appropriate all the behavior of 
a button control object, the dynamic 
message dispatching of TPW, and all the 
other protocols. At this point, though, the 
button doesn’t know how to draw itself. 

Windows uses the m_DrawItem 
message to notify a parent window 
that an owner-draw item needs to be 
painted. A UMDrawItem response 
method, procedure TPVUindow.WMDraw- 
Item, is included in the program's main 
window to decode the parameters of the 
wm_DrawItem message and dispatch a 
message to the correct owner-draw item. 

Once the Drawl tern method for the 
right object type and instance has been 
called, it's time to draw the button. The 
procedure first creates a compatible 
memory device context, selects the bit¬ 
map into the MemDC, and BitBlts the 
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Listing 2 — Cont’d 


type PFonts * A TFonts; 

TFonts « object 

LogPixlX.LogPixlY:Integer; 
constructor Init; 
destructor Done;virtual; 
procedure Relnit;virtual; 
procedure Enumerate(TheDC:hDC) ‘.virtual; 
function At(Index:Integer):pointer;virtual; 
function Count:Integer;virtual; 
function LogPixX:Integer;virtual; 
function LogPixY:Integer;virtual; 
end; 

|★******★★***★****★*★★★*★ implementation **********************} 
implementation 

|★★*★***★★★★★★★*★*★★★★**★ Global Variables 
var 

Faces:PFontCol1ection; 

|TIntObj *★*★★**★★★**★★*★★★★**★★★★★★j 

constructor TIntObj.Init(NewInt:Integer); 

begin 

Int := Newlnt; 

end; 

destructor TIntObj.Done; 
begin 

TObject.Done; 

end; 

|************************ JFontltem **************************j 

constructor TFontItem.Init(NewItern:TLogFont;NewType:Integer); 
begin 

LogFont := Newltem; 

FontType := NewType; 

Sizes := New(PCollection.init(10,10)); 
end; 

destructor TFontltem.Done; 
begin 

Dispose(Sizes.Oone); 

end; 

|★**★★★★★★★★★**★**★**★★★* XFontCollection 

function TFontCol 1 ecti on.Key0f(I tern:Pointer):Pointer; 

var 

Ptr :PChar; 
begin 

Ptr := PFontItem(Item) A .LogFont.IfFaceName; 

KeyOf := Ptr; 

end; 

function TFontCol lection.Compare(Keyl,Key2:Pointer):Integer; 
begin 

Compare := StrIComp(PChar(Keyl),PChar(Key2)); 

end; 

function TFontCol 1 ecti on.GetCount:Integer; 
begin 

GetCount := Count; 

end; 

(************************ jponts **»************»*****) 

constructor TFonts.Init; 

begin 

Faces := New(PFontCollection,Init(100,100)); 

Faces A .Duplicates := False; 

LogPixlX := 0; 

LogPixlY := 0; 
end; 

destructor TFonts.Done; 
begin 

Dispose(Faces.Done); 

end; 
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Listing 2 — Cont’d 


procedure TFonts.Relnit; 
begin 

Dispose(Faces.Done); 

Faces := New(PFontCollection,Init(100,100)); 

Faces A .Duplicates := False; 

LogPixlX := 0; 

LogPixlY := 0; 
end; 

function EnumerateFace(var LogFont: TLogFont; TextMetric: PTextMetric; 

FontType: Integer; Data: PChar): Integer; export; 
begin 

Faces A .Insert(New(PFontItern,Init(LogFont,FontType))); 

EnumerateFace := 1; 
end; 

function EnumerateSize(var LogFont: TLogFont; TextMetric: PTextMetric; 

FontType: Integer; Indx: PChar): Integer; export; 
function DupS(Item:PIntObj):Boolean;far; 
begin 

DupS := (ItenC.Int * LogFont.1fHeight); 
end; 
var 

Result :PIntObj; 

FI:PFontltem; 

Indxx :Integer; 

Error:Integer; 
begin 

Val(Indx,Indxx,Error); 

FI := Faces A .At(Indxx); 

Result := FI A .Sizes A .FirstThat(@DupS); 

if Result = nil then Fi A .Sizes A .AtInsert(0,(New(PIntObj,Init(LogFont.lf- 
Height)))) ; 

Enumerates;'ze := 1; 

end; 

procedure TFonts.Enumerate(TheDC:hDC); 
var 

EnumProc: TFarProc; 

Indx:Integer; 
pIndx:PChar; 

szIndx:Array[0..25] of Char; 

Fontltem :PFontItem; 
begin 

plndx := Pszlndx; 

StrCopy(szIndx,"); 

EnumProc := MakeProcInstance(@EnumerateFace, HInstance); 

EnumFonts(TheDC, nil, EnumProc,nil); 

EnumProc :« MakeProcInstance(@EnumerateSize, HInstance); 
for Indx := 0 to Faces A .Count -1 do 
begin 

Str(lndx.szlndx); 

Fontltem := Faces A .At(Indx); 

EnumFonts(TheDC, Font ItenC.LogFont.1fFaceName, 

EnumProc,plndx); 
end; 

LogPixlX := GetDeviceCaps(TheDC.LogPixelsX); 

LogPixlY := GetDeviceCaps(TheDC,LogPixelsY); 
end; 

function TFonts.At(Index:Integer):Pointer; 
begin 

At := Faces A .At(Index); 

end; 

function TFonts.Count:Integer; 
begin 

Count :* Faces A .Count; 

end; 
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Listing 2 — Cont’d 

function TFonts.LogPixX:Integer; 
begin 

LogPixX := LogPixlX; 

end; 

function TFonts.LogPixY:Integer; 
begin 

LogPixY := LogPixlY; 

end; 

{★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★Ik********************} 

end. 

{ End of File } 


Listing 3 (buttons.pas) 


{Buttons - Extensions to ObjectWindows Copyright (C) Doug Overmyer 7/1/91} 
unit Buttons; 

j************************ interface ***********************} 
interface 

uses WinTypes, WinProcs, WinDos, Strings, WObjects; 
type 

PODButton = ''TODButton; 

TODButton = object(TButton) 

HBmp :HBitmap; 

State:Integer; 

constructor Init(AParent:PWindowsObject; AnID:Integer;ATitle:PChar; 

X,Y,W.H:IntegerjIsDefault:Boolean;BMP:PChar); 
destructor Done;virtual; 

procedure Drawltem(var Msg:TMessage);virtual; 

end; 


The Measure of 
a Great Program. 

PC-METRIC™: The Measurement Tool For Serious Developers. 



PC-METRIC is the software measurement tool 
that measures your code and identifies its most 
complex parts. So you can spend your time 
working in the areas most likely to cause 
problems. 

PC-METRIC is fast, user-configurable, and 
includes a wide array of commonly accepted 
measurement standards. 

Plus, versions of PC-METRIC are available to 
support virtually every popular programming 
language. 

A Great Value By Any Measure. 

PC-METRIC’s price is only $199, and it comes 
with a 30-day money-back guarantee. Multiple 
user discounts are available, as well as site 
licenses and complete source code. 


Order Now! Call (503) 829-7123. 



SET LABORATORIES, INC. 

Quality Tools For Software Craftsmen" 
P.O. Box 868 
Mulino, OR 97042 
Phone: (503)829-7123 
FAX: (503) 829-7220 


COMPUTER 


LANGUAGE 
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MemDC into the button device context. If 
the button is “out,” the origin is xy; if 
the button is "in,” the origin of the bit¬ 
map is offset by 2 (that is, x+2y+2). This 
accounts for the “movement” of the 
button face when it is depressed. 

The routine then uses GDI functions 
to draw the highlights on the face of 
the bitmap; it sets up two polyline ob¬ 
jects drawn with a black, gray, or white 
pen to simulate the shading. The pen 
color is ultimately determined by the 
State variable, which signifies whether 
the button is depressed or has been 
released. (Actually, Windows sends a 
torrent of um_drawitem messages which 
are decoded as needed at the beginning 
of the method by reference to the l- 
Param passed from the parent window.) 

Attractive features of this object in¬ 
clude its ability to inherit standard but¬ 
ton behavior from its ancestor and its 
ability to draw itself without further in¬ 
tervention. The object requires only one 
additional piece of information to sup¬ 
port its behavior - the name of the bit¬ 
map for its face. It does require a mes¬ 
sage dispatching method in the main 
window (the WMDrawItem method), but 
that is essentially a boilerplate opera¬ 
tion. The resulting buttons look just like 
the real thing: when five of them are 
displayed together at the top of the 
window, they function as a quick ac¬ 
cess, custom icon bar. The hardest part 
will be creating the bitmaps that con¬ 
stitute the look! 

The TPW Advantage 

Turbo Pascal for Windows and 
ObjectWindows provide a very helpful 
framework for mastering the Windows 
programming environment. Font 
Preview, with its well-defined objectives 
and limited scope, demonstrates some 
of the features that help bring a daunt¬ 
ing and complex task under control. 
Two OWL features in particular, collec¬ 
tions and inheritance, simplify the 
programming burden in Font Preview. 
The Collections object lets you 
manage remarkably large memory 
structures with comparative ease, while 
Inheritance allows you to derive a 
new button object from an existing ob¬ 
ject, add the behavior you want, and 
save the object for future use. This stuff 
could get addictive. □ 
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Listing 3 — Cont’d 


/************************ 


**********************1 


Implementation 

implementation 

constructor TODButton.Init(AParent:PWindowsObject; AnIO:Integer;ATitie:PChar; 

X,Y,W,H:Integer;IsDefault:Boolean;BMP:PChar); 
begin 

TButton.Init(AParent,AnID,ATitle,X,Y,W,H,IsDefault); 

Attr.Style := Attr.Style or bs_OwnerDraw; 

HBmp :* LoadBitmap(HInstance.BHP); 
end; 

destructor TODButton.Done; 

begin 

DeleteObject(HBmp); 

TButton.Done; 

end; 

procedure TODButton.DrawItem(var MsgrTMessage); 

var 

TheDC,MemDC:HDc; 

ThePen,Pen1,Pen2.OldPen:HPen; 

TheBrush,01dBrush:HBrush; 

OldBitMapiHBitHap; 

LPts,RPts:Array[0..2] of TPoint; 

PDIS ^TDrawItemStruct; 

X,Y,W,H:Integer; 

PenWidth,Offset:Integer; 

DBU:LongRec; 
begin 

Longlnt(DBU) := GetDialogBaseUnits; 

PDIS := Pointer(Msg.lParam); 
if PDIS A .itemAction = oda_Focus then Exit; 
if ((PDISA.itemAction and oda_Select ) > 0) and 
((PDISA.itemState and ods_Selected) > 0) then State 
X := PDISA.rcItem.left; Y := PDISA.rcItem.top; 

W := PDISA.rcItem.right-PDISA.rcItem.left; H := PDISA.rcItem.bottom-PDISA.rcItem.top; 
Offset :* Round(H / (DBU.lo * 4)); {scale highlites based on size} 

Offset; 

0; 

0 ; 

H; 

H; 

H; 

0 ; 


1 else State 


0 ; 


1 = depressed} 


PenWidth 
LPts[0].x 
LPts[l].x 
LPts [2].x 
RPts[0].x 
RPts[1]. 


:= W; LPts[0].y 
:* 0; LPts[l].y 
0; LPts[2] .y 
0; RPts[0].y 
W; RPts[l].y 
RPts[2].x := W; RPts[2].y 
MemDC := CreateCompatibleDC(PDISA.HDC); 

OldBitMap := SelectObject(MemDC,HBMP); 
if State = 0 then BitBlt(PDISA.HDC.X,Y,W,H, MemDC,O.O.SrcCopy) 
else BitBlt(PDISA.HDC,X+OffSet,Y+OffSet,W,H, MemDC,0,0,SrcCopy); 
SelectObject(MemDC,01dBitMap); 

DeleteDC(MemDC); 

Penl := CreatePen(ps_Solid,OffSet,$00000000); 

OldPen := SelectObject(PDISA.HDC.Penl); 

PolyLine(PDISA.HDC,LPts,3); 

PolyLine(PDISA.HDC,RPts,3); 

Se1ectObj ect(PDIS A .HDC,01dPen); 

DeleteObject(Penl); 

LPts[0] .x 


RPts[l].x : 
RPts[2].x : 
if State = 
begin 
Penl 


W-OffSet; 

LPts[0].y 

= Offset; 

Offset; 

LPts[1].y 

= Offset; 

Offset; 

LPts[2].y 

= H-OffSet 

Offset; 

RPts[0].y 

= H-OffSet 

W-OffSet; 

RPts[l].y 

= H-OffSet 

W-OffSet; 

RPts[2].y 

* Offset; 


0 then 


CreatePen(ps_Solid,PenWidth,$00FFFFFF); 
Pen2 := CreatePen(ps Sol id,PenWidth,$00808080); 
end 
else 
begin 

Penl := CreatePen(ps_Solid,PenWidth,$00808080); 

Pen2 := CreatePen(ps_Solid,Penwidth,$00808080); 

end; 

OldPen := SelectObject(PDIS A .HOC,Penl); 
PolyLine(PDISA.HDC,LPts,3); 
Select0bject(PDISA.HDC,Pen2); 

DeleteObject(Penl); 

PolyLine(PDIS A .HDC,RPts,3); 

SelectObject(PDISA.HDC,OldPen); 

DeleteObject(Pen2); 
end; 
end. 

{ End of File } 


{white hilite} 


{black hilite} 


IF YOU PROGRAM 

in C, C++, Bask, Fortran, Cobol, 
Pascal, dBase, 

HI-SCREEN Proll 

is your user interface solution 



With HI-SCREEN Pro II you can design modern 
text and graphic user interfaces in a snap: 

>- Design interface objects using interactive 
editors. Generate all windows, icons, menus, 
and data entry screens in a WYSIWYG fashion. 

>- Test all objects directly under the editors, 
including data validation, menus, icons and 
dialog boxes. 

► Manage objects from your program using a set 
of versatile and powerful functions. 


Hercules, CGA, EGA, VGA, 25/30/43/50 line modes 
(outo-detect) • Full mouse support & keyboard 
control • Automatic data validation • Screen editor 
functions include: view, load, merge, copy, delete, 
color, draw (using any character), frame (standard, 
30, round corners), undo, on-line ASCII table, merge 
graphic screens & icons for hypertext effects, direct 
access to other editors (icon editor, menu editor, 
graph editor, etc.) • Field types: alphanumeric, real, 
integer, long text, chosen characters, date, time, list, 
mouse box, selector, password, flag button • Field 
description: type, ranae, format, access key, 
justification, color, help message or screen, etc. • 

Data entry test mode under the editor • Automatic 
context-sensitive help systems • Automatic scrolling 
windows with scroll bars & boxes • Automatic 
shadowing effects • Combine text and graphics • 
Capture any text and graphic screens • Flexible input 
management: field-by-field or full-screen, interrupt 
input before or after field, run parallel task, check 
current field, etc. • Automatic menu systems: pull¬ 
down, horizontal, vertical • link screens into your 
.EXE or keep a separate library file • Only S395 • No 
royalties • Call for OS/2 and Windows 3 modules. 

CALL: 1-800-338-2852 


li : ij See us at 
IIIMIllIl Booth 

Software #909 

DEVELOPMENT^ 

Softwoy, Inc. 

185 Berry Street, Suite 5411, San Francisco, CA 94107 
Tel.: 415-896-0708 • Fax: 415-896-0709 
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Windows™/DOS Developer’s Journal 

Call For Papers 


Windows/DOS Developer’s Journal is seek- Wlndows/DOS Developer’s Journal 


ing articles on the topics below. If you have an 
idea for a related story and experience that 
would especially qualify you to write on one of 
these topics, contact the Wlndows/DOS 
Developer’s Journal editorial staff for Author 
Guidelines at: 


1601 W. 23rd St., Suite 200 
P.O. Box 3127 
Lawrence, KS 66046-0127 
(913) 841-1631 
FAX (913) 841-2624 


Debugging 

■ Proposals due 216192 
manuscripts due 3/12/92 

Suggested topics: Using 

hardware debuggers. assert()- 
style macros for Windows. Using 
protected-mode to catch stray 
pointers. Debugging NLM ap¬ 
plications. How to debug Win¬ 
dows 3.1 programs with tool- 
help.dll. 


TOPICS 


Efficiency 

■ Proposals due 3/5/92 
manuscripts due 4/10/92 

Suggested topics: How to use 

the Windows GDI efficiently. 
Using the UART FIFO queue for 
efficient serial data transfer. Run¬ 
time detection and utilization of 
286/386/486 features. An efficient 
subsegment memory allocator 
for Windows. Tuning network I/O 
for maximum throughput. 


Graphical User Interfaces 

■ Proposals due 4/3/92 
manuscripts due 518192 

Suggested topics: Program¬ 
ming in a pen-based environ¬ 
ment. Porting between Windows 
and the Macintosh. 


We prefer very practical and detailed treatments of 
real problems encountered when working on PC 
platforms. Topics should be of practical interest to 
professional developers working under DOS or Win¬ 
dows. Topics must be PC-specific in some way; 
portable, general-purpose algorithms, for example, 
are not acceptable. Accompanying code may be in 
BASIC, Pascal, C, assembly, C+ + , or another lan¬ 
guage if the nature of the story requires it. 


We pay at rates competitive with other national 
technical journals and provide better editorial assis¬ 
tance than most. 

Proposals should include a short abstract, a one- 
page outline, and a brief resume of the author’s 
qualifications. When mailing the proposal, please 
include a hard copy and an ASCII text file on an 
MS-DOS formatted disk. 


Windows/DOS Develop, 


er’s Journal 
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Paul Bonneau 


You may address Win¬ 
dows questions to Paul in 
care of Windows/DOS 
Developer's Journal a t 
1601 W. 23rd St., ste. 200, 
P.o. Box 3127, Lawrence, 
KS 66044-0127, or you 
may contact him via in¬ 
ternet as 

bonneau@hyper. hyper.cow. 


N ote: In the January 1992 issue (3:1, p. 9), the instruction for allocating global 
memory for an Edit I tern (part 5 of the answer to Charles Roth's question) 
should read: “allocate a block of global memory using GMEM_M0VE- 
ABLE | GMEM_ZEROINIT\GMEM_DDESHARE ..." Without the last flag, the debugging kernel 
will RIP. 


Q Does anyone know of a sleazy hack to determine if a combo box's listbox is 
down? This is useful when you want to use the CBN_SELCHANGE notification 
only after the listbox is put away. Actually, a notification of the listbox being put 
away would be better than polling the control with a message. 

I understand that both a message and a notification are available under 3.1. But I 
can't wait. 

David Lee 
dlee@inference.com 

A Modifying the behaviour of a predefined Windows class is always a bit of a 
sleazy hack, but in this case, I can’t think of a cleaner way to do it. The techni¬ 
que that comes to mind is to superclass the ListBox component of the ComboBox. 
Whenever the ListBox window is about to be removed, it will receive a UM_SHOUUIN- 
DOU message with a non-zero wParam. A superclass procedure would at this point 
notify its parent that it is being collapsed. 


Paul Bonneau is the senior software design engineer for Hypercube, Inc., #7-419 
Phillips St, Waterloo, Ontario, Canada, N2L 3X2. His current project is HyperChe m, a 
molecular modelling software package for Windows. Paul has been developing Win¬ 
dows applications for 5 years. Much of his expertise was gained at Microsoft, where 
he implemented a library module used by all of Microsoft’s major Windows applica¬ 
tions. 






















A problem with this is that the ListBox window is a child of 
the desktop window, not of the ComboBox's parent (this al¬ 
lows the ListBox to drop down outside of a DialogBox's win¬ 
dow). Also, the ListBox does not store a control ID, something 
that is required for a standard UM_COMMAND message. Instead, 
the first user-definable window word of the ListBox window is 
a near pointer to a small block of memory in the USER heap. 
The first word of this memory is the window handle of the 
ComboBox itself. To indirect through the near pointer requires 
that you obtain the USER default data segment selector, 
(which is an even sleazier hack!). 

At this point you are relying on intimate details of the 
ComboBox implementation. But since Windows 3.1 does pro¬ 
vide the required notification, you can perform a version 
check and only use the hack for version 3.0. One other im¬ 
plementation detail is the name of the class for the special 
listbox. Unlike other Windows predefined classes, which have 
class names like "#32767," this one is called “ComboLBox.” 


It is curious that Windows supports the very powerful 
technique of superclassing a system class but Microsoft does 
not make public the names of all the system classes. Perhaps 
as Windows evolves over time, Microsoft will provide a more 
orthogonal relationship between system classes and the user 
API. 

Listing 1 presents code for a DLL to implement the super- 
classer. If the Windows version is not 3.0, LibMainf) returns 
FALSE which prevents the DLL from being loaded. When the 
superclass proc, ComboFilterf) , detects that it is being hid¬ 
den, it obtains the parent window handle and control ID and 
notifies its parent with a WM_COMMAND message using the 
notification code CBN_COLLAPSED. I have defined CBN_C0L- 
LAPSED to be one greater than the highest Combo notification 
available in version 3.0, CBN_DROPDOUN. You can use any value 
you like. 

Listing 2 is the linker definition file, Listing 3 the makefile, 
and Listing 4 is a public header file that simply defines the 
new notification message. 


Listing 1 (combo.c) 

Idefine NOCOMM 


linclude ‘windows.h> 

int FAR PASCAL 

linclude "combo.h" 

WEP(short wCode) 

/ ***************************************************** j 

FARPROC lpfnCombo; 

/* -- The usual do-nothing stub. */ 

HANDLE hmemUser; 

^*****************************************************^ 

typedef struct 

l 

return FALSE; 

l 

WORD rgw[31]; 

/ 

HWND * phwnd; 

LONG FAR PASCAL 

} LBW; /* List Box Window handle. */ 

ComboFilter(W0RD hwnd, WORD wm, WORD wmp, DWORD lwmp) 

/***************************************************** j 

#define szComboListClass "ComboLBox" 

/* .. Superclasser for ComboBox ListBoxes. */ 

/* -- hwnd : Main window. */ 

LONG FAR PASCAL ComboFiIter(WORD, WORD, WORD, 

/* -- wm : Message type. */ 

DWORD); 

/* — wmp, lwmp : Message parameters. */ 

int FAR PASCAL LibMainfHANDLE, WORD, WORD, LPSTR); 

^*****************************************************y 

int FAR PASCAL WEP(short); 

l 

if (wm == WM SH0WWIND0W && wmp ■== 0) 

int FAR PASCAL 

( 

LibMain(HANDLE hins, WORD ds, WORD cbHeap, LPSTR lsz) 

WORD dsUser = HIW0RD(G1obalLock(hmemUser)); 

y*****************************************************^ 

WORD dsLocal; 

/* -- hins : This library's instance. */ 

HWND hwndCombo; 

/* -- ds : The library's default data segment */ 

HWND hwndParent; 

/* -- cbHeap : Size of out local heap. */ 


/* — lsz : Command line invoked with. */ 

asm mov dsLocal, ds; /* Save ds. */ 

/***************************************************** j 

_asm mov ds, dsUser; /* Get USER ds. */ 

\ 

WORD wVersion = GetVersion(); 

/* Get main combo window, so we can extract */ 

WNDCLASS wcs; 

/* the control id used to notify our owner. */ 
hwndCombo « *((LBW *)hwnd)->phwnd; 

/* Only need patch for version 3.0. */ 


if (LOBYTE(wVersion) != 3 || HIBYTE(wVersion) != 0) 

asm mov ds, dsLocal; /* Restore ds. */ 

return FALSE; 



/* In case of REAL mode. */ 

/* Get USER'S default data segment. */ 

Global Unlock(hmemUser); 

if ((hmemUser * LoadLibraryCuser.exe")) »* 0) 

hwndParent = 

return FALSE; 

GetWindowWord(hwndCombo, GWW_HWNDPARENT); 
if (hwndCombo != NULL && 

/* Superclass the ComboBox ListBox class. */ 

IsWindowVisible(hwndParent)) 

GetClassInfo(NULL, szComboListClass, &wcs); 

SendMessage(hwndParent, WM COMMAND, 

lpfnCombo = (FARPROC)wcs.lpfnWndProc; 

GetWindowWord(hwndCombo, GWW ID), 

UnregisterClass(szComboListClass, NULL); 

MAKEL0NG(hwndCombo, CBN COLLAPSE)); 

wcs.lpfnWndProc = ComboFiIter; 

) 

RegisterClass(&wcs); 

return CallWindowProc(lpfnCombo, hwnd, wm, wmp, 
lwmp); 

return TRUE; 

i 

i 

/* End of File */ 

DLL to Patch ListBox of ComboBox 
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Listing 2 (combo.def) 


LIBRARY 

Combo 


EXETYPE 

WINDOWS 


CODE 

PRELOAD 

MOVEABLE DISCARDABLE 

DATA 

PRELOAD 

SINGLE 

HEAPSIZE 

0 


EXPORTS 

WEP 

@1 

RESIDENTNAME 

ComboFilter @2 


Linker Definition File for mlefix DLL 


To use the DLL, just put it on the L0AD= line of your win. ini. 

Q l need your help! I have written a custom edit control. 

That control is used inside a dialog box. One of the 
problems is that I don't get m_CHAR messages, only 
UM_KEYDOUN and WM_KEYUP. This problem I have already solved. 
The problem I still have left is that, every time I press a key, 
Windows beeps at me. The keypress still gets sent to the edit 
control, but it appears that the dialog box does not know that 
the control is processing the keystroke. As a result, it thinks I 
want to jump to another control (for example, jump to the 
SFilename edit box using “F”) etc. When I press a character 
that actually corresponds to the accelerated character of 
another control, I don't get the beep. However, that control 
will flash, indicating that it is receiving the keystroke. 


Listing 3 (makefile) 

all: combo.exe 

combo.obj: combo.c 

cl -c -AMw -Gsw -Os -Zdpe -W3 combo.c 

combo.exe: combo.obj combo.def 

link /m combo 1ibentry.combo,,1ibw mdllcew,combo 
rc combo.exe 


Project File for Combo Patch DLL 


Listing 4 (combo.h) 

Idefine CBN COLLAPSE CBN DROPDOWN + 1 


Interface to ComboBox Patch DLL 


I return TRUE for all WM_KEYDOUN messages I get. I did not 
call DefUindowProc (). That means that the dialog box should 
know that I am processing the message myself, right? 

Help! 

Stephen Chung 
s tephenc@cunixf. cc.columbia.edu 







Tossing for T-shirts.. 

AND OTHER UNUSUAL PRIZES! 


Visit us at the Windows/DOS booth — 
Software Development ’ 92 . Take a few 
minutes to chat with our editor, Ron Burk. 
And while you’re there, take a chance on the 
Windows/DOS “game of chance.” Break our 
Window and win a free subscription, 
fashionable T-shirt, or programming book! 

Windows/DOS 


Booth 408 

Software Development ’92 
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A You are very close. I would guess that your problem is 
that your custom control is not responding with 
DLGC_UANTCHARS to the WM_GETDLGCODE message. This message 
is sent by IsDialogMessage() as part of the keyboard mes¬ 
sage translation process. If a control responds with this bit set, 
a UM_CHAR message is generated for the keystroke, and fur¬ 
ther processing of the keystroke is prevented. If this bit is not 
set, IsDialogMessagef) will look for a control with a cor¬ 
responding keyboard accelerator, and will activate the control 
if it exists, or beep if not. 

Q How can one display an hourglass cursor when a modal 
dialogbox is present? 

A Windows will set the cursor shape in response to the 
UM_SETCURSOR message. So when all else fails, you can 
trap this message in your application's main windowproc and 
call SetCursor() yourself. 

But watch out! The implementation of the UM_SETCURSOR 
case in DefUindowProc () is one of the more arcane aspects of 
Windows. Windows actually uses this innocuous little mes¬ 
sage to change the activation and z-ordering of top level win¬ 
dows! When a top-level window is disabled due to the 
presence of a modal dialog box (or simply is the owner of an 
enabled popup window), another application is active, and the 
user clicks on your application, DefUindowProc () will bring 
your application's window to the top of the z-stack and ac¬ 
tivate the popup. This monumental kludge works in concert 



with a low cost 

DataScope™ 

Alterable character sets 


^asterCard^ 


• Alterable character sets 

• Macro display recording 

• Up to four user-alterable, 
multitasking display windows 

• Microsecond timestamps 

• Laptop color support 

• Free demo diskette 

• Hypertext help 

"DataScope has been 
indispensable in our 
protocol work!" . forth, Inc. 

Paladin Software, Inc. 
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with GetMessagef), which is responsible for generating the 
UM_SETCURSOR messages in the first place. 

So, to achieve the effect you want, and still let your ap¬ 
plication be brought to the top of the z-stack when it gets 
clicked on and the dialog box is present, you need to call 
DefUindowProc(). It will change your cursor to an arrow, and 
about the best you can do is change it right back to an 
hourglass. This will happen so quickly that the user may be 
able to detect just a bit of flicker where the cursor is. You can 
minimize this flicker by mimicking the UM_SETCURS0R code in 
DefUindowProc (). 

DefUindowProc () only performs this kludge when the high 
word of IParam is UM_LBUTT0ND0UN and the low word is 
HTERROR. Thus if you are in hourglass cursor mode and IParam 
meets these criteria, call DefUindowProc() followed by Set- 
Cursor(). Otherwise, don’t bother to call DefUindowProc(). If 
you are not in hourglass cursor mode, however, you should 
let DefUindowProc () do your cursor setting for you, since it 
will make the appropriate change to the shape of the cursor if 
it is over the border of your application’s main window. 

The code in Listing 5 demonstrates this idea. It implements 
a routine called MySetCursorO where the parameter hcsr is 
a handle to the hourglass cursor, loaded at initialization time 
via LoadCursorfNULL, IDC_UAIT). If hcsrUait is NULL, Def¬ 
UindowProc () is used to set the cursor. Call the routine from 
the UM_SETCURS0R case of your main window procedure. Pass 
NULL via hcsrUait if you are not in hourglass cursor mode. 

Q Can I create a caption for an edit child control? I call the 
following CreateUindow() function in my program to 
create an edit child. The edit child appears, but with no cap¬ 
tion. Any suggestions? 

hwndedit = CreateWindow( 

"edit", "edit", 

WS_CHILD | WSVISIBLE | 

WS_0VERLAPPEDWIND0W | 

WS_CAPTI0N | WSJSCROLL | 

WS_VSCR0LL j WSJ3VERLAPPED | 

ES_LEFT | ES_MULTILINE | 

ES_AUT0HSCR0LL | ES_AUT0VSCR0LL, 

0, 0, 0, 0, 

hWnd, 1, hlnstance, NULL); 

Thank you in advance... 

Amari Elammari 
P.O. BOX 1236 
Wolfville, N.S. 
Canada BOP 1X0 

A This is not as easy as it looks. At first I thought the prob¬ 
lem was due to the use of both US_OVERLAPPED and 
US_CHILD. A window cannot be both an overlapped window 
and a child - they are mutually exclusive. But windows.h 
defines US_OVERLAPPED as 0, so the US_CHILD style would 
simply override it. I tried removing the US_CHILD style, but the 
result still had no caption. It is interesting to note that there is 
a hidden system menu in this case, even though there is no 
caption. Press and release the ALT key and a small square in 
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Listing 5 (cursor.c) 


VOID 

MySetCursor(HWND hwnd, WORD wm, WORD wmp, DWORD lwmp, 
HCURSOR hcsr) 

I*********************************************★*★★*★**j 


/* -- Handle the WM_SETCURSOR message. */ 
/* -- hwnd : Window receiving message. */ 
/* -- wm : Message number. */ 
/* -- wmp : Word sized message parameter. */ 
/* -- lwmp : Long word sized message parameter. */ 
/* -- hcsr : Cursor to display. Use NULL for */ 
/* default. */ 


{ 

if (hcsr == hcsrNull) 

{ 

DefWindowProc(hwnd, wm, wmp, lwmp); 

) 

else 

( 

/* Don't prevent DefWindowProcO form */ 

/* performing its hand in the kludge to make */ 
/* this application the active one! */ 
if (HIWORD(1wmp) == WM_LBUTT0ND0WN && 
LOWORO(lwmp) == HTERROR) 

DefWindowProc(hwnd, wm, wmp, lwmp); 

SetCursor(hcsr); 

) 

} 

/* End of File */ 

Routine to Change the Cursor 
Even if a Dialog Box is Present 


Listing 6 (mlecptn.h) 


/* Public prototypes. */ 

BOOL FlnitCaptionedMle(HANDLE); 

HWND HwndCaptionedMle(HWND, RECT *, char *, BOOL); 


j***************************************************** J 

/* Macro to set title of Captioned MLE. */ 

/* -- hwnd : Window handle returned by */ 

/* HwndCaptionedMle(). */ 

/* -- lsz : Title string. */ 

J*****************************************************j 

Idefine SetMleText(hwnd, lsz) \ 

SetWindowText(GetWindow((hwnd), GW_CHILD), (lsz)) 

j***************************************************** j 

/* Macro to get title of Captioned MLE. */ 

/* -- hwnd : Window handle returned by */ 

/* HwndCaptionedMle(). */ 

/* -- lsz : Title string. */ 

/* -- cb : Maximum size of title in bytes. */ 

^***********★*★★******★*★***************************** ^ 
Idefine GetMleText(hwnd, lsz, cb) \ 

GetWindowText(GetWindow((hwnd), GW_CHILD), (lsz), \ 
(cb)) 


/* End of File */ 


Interface to Module to Implement a Captioned MLE 


the upper left-hand corner of the window will invert. Press the 
space bar and a system menu will appear beneath it. 

After doing a bit of disassembling of the edit control's code, 
I found out that the edit control was explicitly removing the 
WS_B0RDER style from the window. Since WS_CAPTION is 
defined to be WS_B0RDER \ WS_DLGFRAME in windows.h, the 
effect is to remove the caption. After a bit of pondering, this 
made sense. The problem arises because of the WM_SETTEXT 
and WMJGFTTEXT messages. If you send one to an edit control, 
the text in the body of the edit control gets set or retrieved. 
For a window with a caption, these messages affect the cap¬ 
tion. So when it comes to an edit control with a caption, there 
is ambiguity as to whether to apply the message to the cap¬ 
tion or the body of the control. 

Windows solves this problem rather pragmatically by disal¬ 
lowing captions on edit controls. One can get around this 
limitation of course, and I gave it a try. After creating the edit 
control with the above styles, I used SetWindowLongf) to 
replace the WS_B0RDER bit in the window style. This was fol¬ 
lowed by a call to MoveWindow() , to generate a WM_NCSIZE to 
force the edit control to recalculate the size of its client area. 

At first glance, the resulting window looked exactly like 
what was required, it had a border, and the user could type 
text in the client area, but problems quickly became apparent. 
After entering some text in the control, then causing the edit 
to be repainted by dragging it off-screen and back again, the 
caption contained the text from the body! The caption could 
be patched up with a call to DefWindowProcO directly, using the 
WM_SETTEXT message, but this would be a very cumbersome 
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kludge to implement, since the call would potentially have to 
be made every time the non-client area was painted. 

At this point it seems a much better solution would be to 
create two windows. The first would be a dummy window, 
whose only purpose would be to have a caption. The second 
window would be the actual edit control, created as a child of 
the dummy window, sized to fill the dummy window's client 
area. The overhead in this solution is that a class has to be 
registered for the dummy window. Since the dummy window 
doesn't have to do any work itself, you can just use Def- 
WindowProc() as the window procedure when registering its 
class. This saves an export in the linker module definition file. 

Listings 6 and 7 implement a module to create the cap¬ 
tioned multiline edit (MLE). Listing 6 is the public header file 
that defines the interface to the module. Listing 7 implements 
the module. Call FlnitCaptionedMlef) during the initialization 
of the first instance of your application, when the previous 
instance handle passed to UinMainf) is NULL. 

HwndCaptionedMlef) will create the two windows that 
comprise the MLE and return a window handle to the parent 
window. This routine can create the parent as either a popup 
or a child window. If the /Popup parameter is clear, it creates 
the parent of the MLE as a child of hwndOwner. The resulting 
window will be clipped to the client area of hwndOwner and 
will never get activated, even though it can receive the focus. 
If the f Popup parameter is clear, the MLE’s parent is created as 
a popup window that is free to move anywhere on the 
desktop, but which will be destroyed when hwndOwner is, and 
will disappear if hwndOwner is minimized. 
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To get rid of the window via program control, pass the 
window handle returned from HwndCaptionedMle() to 
DestroyUindow(). 

Two convenience macros are also provided in mlecptn.h, 
SetMleText () and GetMleText(). These set and get the text 
of the MLE. To set or retrieve the caption, just use SetUindow- 
Text() and GetWindowText(). 

Q Dear Mr. Bonneau: 

I found your internet address in Windows/D OS 
Developer's Journal and would like to welcome you and con¬ 
gratulate you on your new column. It's always nice to read 
articles by people who seem to know what they are talking 
about. 

I have a question about Windows programming for which I 
would greatly appreciate any comments or hints you may 
have. 

As part of a government contract project I am working on I 
will need to incorporate some hypertext capabilities into my 
program. Of course I could simply write it in the form of Rich 
Text Format help text and use the Windows Help Engine to 
supply the hypertext capability, but I would like to keep 
everything internal to my program. So I have been wondering 
how hypertext can be implemented in Windows and the only 
solution I can come up with is by creating a child text window 
without borders for every text segment which is to exhibit 
hypertext functionality, filling that child window with that text, 
setting the icon for that window to be the pointing hand, and 
then placing these child windows strategically in the remain¬ 
ing text to make it seem like a continuous paragraph. 

What I don't like about this idea is that it sounds tedious 
and messy. It seems to me that there should be a more 
elegant solution to solve the problem. 

I would greatly appreciate any ideas you might have. 
Thanks in advance for your time and effort. 

Gil Romano 
soharlgilOcs.ucla.edu 

A Thank you for the welcome. I certainly agree with you 
that creating child windows for the "hot’’ text items 
would be messy. However, a window does provide necessary 
functionality that you will have to duplicate if you do not use 
them. Hit detection is probably the most important. When the 
user clicks down on a window, a UM_LBUTT0ND0UN, UM_MBUT- 
TONDOUN, or WM_RBUTT0ND0WN message is delivered to the win¬ 
dow (depending on which mouse button was depressed). 
Without using child windows, the hypertext window would 
have to determine which if any of the hot text elements 
enclosed a mouse down message. 

Also, as you point out, you can set the class cursor for a 
window, and just let Windows take care of changing the 
shape of the cursor when it is over a child of that class. If you 
do not use child windows, for each UM_M0USEM0VE (or UM_SET- 
CURSOR ) message, the hypertext window must determine 
which type of text region is under the cursor and set the 
shape appropriately. 

The big disadvantage with using child windows containing 
their own text is lining them up with the rest of the text. This 
can be a hard problem to solve if you want a solution general 
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Listing 7 (mlecptn.c) 


finclude <windows.h> 
linclude "mlecptn.h" 

/* Class name for MLE's parent. */ 

Idefine szCaptionedMleClass "CaptionedMle" 

BOOL 

FInitCaptionedMle(HANDLE hins) 


/* -- Create a class for the MLE's parent window. */ 
/* -- Call this routine when initializing the first */ 
/* instance of the application. */ 
/* -- Return false if the class could not be */ 
/* registered. */ 
/* -- hins : Application's instance handle. */ 


{ 

WNDCLASS wcs; 

/* The parent window doesn't have to do anything */ 
/* except call DefWindowProcO, so we take the */ 

/* easy way out and just use DefWindowProcO as */ 

/* the window proc itself. */ 

wcs.style - CS_HREDRAW | CS_VREDRAW; 

wcs .1pfnWndProc = DefWindowProc; 

wcs.cbClsExtra ■ 0; 

wcs.cbWndExtra * 0; 

wcs.hlnstance * hins; 

wcs.hlcon • LoadIcon(NULL, IDI_APPLICATION); 
wcs.hCursor - LoadCursor(NULL, IDC_ARR0W); 
wcs.hbrBackground = GetStockObject(WHITE_BRUSH); 
wcs.lpszMenuName = NULL; 
wcs.lpszClassName = szCaptionedMleClass; 
return RegisterClass(&wcs); 

} 


HWND 

HwndCaptionedMle(HWND hwndOwner, RECT * prect, 
char * szCaption, BOOL fPopup) 


/* -- Create an MLE with a captioned parent. */ 
/* -- Return the window handle of the parent. */ 
/* -- hwndOwner : Window to own parent. */ 
/* -- prect : Location of parent window. */ 
/* -- szCaption : Title to put in caption. */ 
/* -- fPopup : Create parent as a popup window if */ 
/* set, otherwise as a child. */ 


{ 

RECT rect; 

HWND hwnd; 

HANDLE hins; 

hins « GetWindowWord(hwndOwner, GWW_HINSTANCE); 

/* Create the MLE's parent. */ 
if ((hwnd ■ CreateWindow( 
szCaptionedMleClass, 
szCaption, 

WSJISIBLE | WS_CAPTION | 

(fPopup ? WS_P0PUPWIND0W : 

(WSCHILD | WS_B0RDER | WS_SYSMENU)), 
prect->left, 
prect->top, 

prect->right - prect->left, 
prect->bottom - prect->top, 


Interface to ComboBox Patch DLL 


hwndOwner, 

NULL, 

hins, 

NULL)) == NULL) 
return NULL; 

/* Create the MLE to just fill the client area. */ 
GetClientRect(hwnd, &rect); 
if (CreateWindow( 

“edit", 

NULL, 

WS_CHILD | WSJISIBLE | WS VSCROLL | ES_LEFT | 
ES_MULTILINE | ES_AUTOHSCROLL | ES_AUT0VSCR0LL, 
rect.left, 
rect.top, 

rect.right - rect.left, 
rect.bottom - rect.top, 
hwnd, 

0 , 

hins, 

NULL) — NULL) 

( 

DestroyWindow(hwnd); 
return NULL; 

) 

return hwnd; 

) 


/* End of File */ 



vimoge o(leno.tif); 

//remove (ate from image 
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enough to support an arbitrary font. If the child windows were 
transparent, however, then you could simply use the full text 
window to contain all the text and the child windows as hit 
detectors. The placement of the child windows would be 
much less critical, and easier to position. 

Listings 8 and 9 present a sample window class that could 
be used for such a child window. The window simply returns 
TRUE when it receives the UM_ERASEBKGND message, and calls 
BeginPaintf) and EndPaint() when it receives the UM_PAINT 


Listing 8 (transbtn.h) 

/* Class name for transparent button control. */ 

#define szTransButtonClass “TransButton" 

/* Routine creates the control class. */ 

BOOL FCreateTransButtonClass(HANDLE, HCURSOR); 

/* End of File */ 

Interface to Transparent Button Control Module 


message, but performs no graphical output. Since the window 
is a child, you can use the hMenu parameter of the Create- 
Uindow() call to contain a control ID, just as you would for a 
control in a dialog box. This ID can be used to associate the 
window with the jump data. When the user clicks down on 
the window, it generates a UM_COMMAND message with a 
notification of BN_CLICKED. 

If you do want a solution general enough to handle ar¬ 
bitrary fonts, you can position the windows algorithmically, 
instead of by hand. For each hot text item, you can determine 
its starting point within the hypertext window by using Get- 
TextExtentf) with a string containing the text that precedes 
the hot text item. You can similarly find the end point by 
using a string containing both the preceding text and the hot 
text item. 

One word of caution. If you decide to use this technique, 
make sure you do not use the WS_CLIPCHILDREN style for the 
hypertext window. If you do, each child will end up looking 
like a hole in its parent. 

Paul Bonneau 

bonneau@hyper.hyper.com □ 


Listing 9 (transbtn.c) 


linclude <windows.h> 
finclude ''transbtn.h 11 

DWORD FAR PASCAL TransButtonWndProc(HWND, WORD, 
WORD, DWORD); 

BOOL 

FCreateTransButtonClass(HANDLE hins, HCURSOR hcsr) 

j*****************************************★★*★****★***J 


/* -- Create a window class for the control. */ 
/* -- Call this routine when initializing the first */ 
/* instance of the application. */ 
/* -- Return false if the class could not be */ 
/* registered. */ 
/* -- hins : Application's instance handle. */ 
/* -- hcsr : Class cursor. */ 


( 

WNDCLASS wcs; 
wcs.style = 0; 

wcs.lpfnWndProc = TransButtonWndProc; 

wcs.cbClsExtra = 0; 

wcs.cbWndExtra * 0; 

wcs.hlnstance = hins; 

wcs.hlcon = NULL; 

wcs.hCursor = hcsr; 

wcs.hbrBackground * NULL; 

wcs.lpszMenuName = NULL; 

wcs.lpszClassName * szTransButtonClass; 

return RegisterClass(&wcs); 

) 


DWORD FAR PASCAL 

TransButtonWndProc(HWND hwnd, WORD wm, WORD wmp, 

DWORD lwmp) 

j *★★★*★★★*★**★**★★*★********★*************************^ 


/* -- Window procedure for transparent control. */ 
/* -- hwnd : Window receiving message. */ 
/* -- wm ; Message number. */ 
/* -- wmp : Word sized message parameter. */ 
/* -- lwmp : Long word sized message parameter. */ 


^*****************************************************y 

{ 

switch (wm) 

{ 

default: 

return DefWindowProc(hwnd, wm, wmp, lwmp); 

case WM_ERASEBKGND: 
break; 

case WM_PAINT: 

( 

PAINTSTRUCT wps; 

/* Need to call BeginPaint()/EndPaint() so */ 

/* that the WM_PAINT messge gets removed */ 

/* from the queue. */ 

BeginPaint(hwnd, &wps); 

EndPaintfhwnd, &wps); 

) 

break; 

case WM_LBUTT0ND0WN: 

SendMessage(GetParent(hwnd), WM_C0MMAND, 
GetWindowWord(hwnd, GWW_ID), 

MAKELONG(hwnd, BN_CLICKED)); 
break; 

) 

return TRUE; 

) 

/* End of File */ 


Module to Implement a Transparent Button Control 
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OS/2 Power 
Under Dos 

Guy Eddon 

OS/2 offers significant advantages over DOS, such as ad¬ 
dressing up to 16 megabytes of memory, and the ability to 
multithread and multitask. These features are also possible 
under DOS, however, using a method that makes them easier 
to use, faster, and cheaper than their OS/2 counterparts. Using 
Phar Lap's 2861 DOS-Extender in conjunction with Microsoft C 
5.1 or 6.0, or the Microsoft Macro Assembler 5.1 or 6.0, you 
can incorporate these capabilities in your DOS programs. 

The Phar Lap 2861 DOS-Extender is currently the only ex¬ 
tender that uses Microsoft's OS/2 libraries instead of supplying 
its own. Other DOS extenders supply their own libraries and 
thus may not be OS/2 compatible. 

That 2861 DOS-Extender supports OS/2 function calls is not 
documented. Careful reading of the Phar Lap manual does dis¬ 
close a partial list of supported OS/2 functions, but rendered 
with this list is a disclaimer stating that 2861 DOS-Extender 
may be able to run some OS/2 programs under DOS. Nowhere 
is it stated, however, that you can write a complete OS/2 ap¬ 
plication, taking nearly full advantage of a rich operating sys¬ 
tem, and run it completely under DOS. This capability opens 
the door to the enormous base of DOS users. 

Incorporating OS/2 Functionality 

Phar Lap’s 2861 DOS-Extender allows any C or assembler 
program to linearly access 16 megabytes of memory. For in¬ 
stance, suppose you have a large program that uses overlays 
and EMS or XMS memory to squeeze under DOS’s 640K barrier. 
Phar Lap’s 2861 DOS-Extender frees your program from this 
limitation. The program can access up to 16Mb of extended 
memory to store code and data. 

2861 DOS-Extender also lets you create multithreaded 
and/or multitasking applications under DOS. For example, sup¬ 
pose your current project must transmit and receive data 
from multiple sites concurrently. Such a project would require 
multithreading capabilities. 

To obtain these ''non-DOS" capabilities, compile or as¬ 
semble your program normally, then link it with the OS/2 
libraries, bind it with Phar Lap’s 2861 DOS-Extender, and ex¬ 
ecute it at the command line under DOS. You now have an 
OS/2 protected-mode program running under DOS. 


Guy R. Eddon is an independent computer consultant now 
writing financial applications under Windows for Dun & 
Bradstreet In his free time Guy writes computer programs for 
people with autism and other mental disabilities. He can be 
reached at 30-07 Hey wood Ave., Fairlawn, NJ 07410 (201) 797-1567. 
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Table 1 



OS/2 Function 

Description 

Thread Management 

DosCreateThread 

DosEnterCritSec 

DosExit 

DosExitCritSec 

DosGetPrty 

DosResumeThread 

DosSetPrty 

DosSuspendThread 

DosSleep 

Creates new thread of execution within same process 
Freezes other threads in same process 

Terminates current thread 

Unfreezes other threads in current process 

Gets thread priority 

Reactivates specific thread 

Sets thread priority 

Suspend specific thread 

Suspends thread for x milliseconds 


Process Management 




DosCwait 

Checks child process 



DosExecPgm 

Runs child process 



DosExit 

Terminates current process 



DosExitList 

Registers routines executed at process termination 



DosGetPID 

Return PID of current process and its parent 



DosKillProcess 

Terminates another process 



DosPTrace 

Inspects/modifies/traces child process 



DosFlagProcess 

Send event-flag signal to another process 



DosGetEnv 

Returns selector for process's environment 



Semaphore Management 




DosSemClear 

Clears a semaphore 



DosSemRequest 

Attempts to get ownership of a semaphore 



DosSemSet 

Sets a semaphore 



DosSemSetWait 

Sets a semaphore, and wait until it is cleared 



DosSemWait 

Waits until a semaphore is cleared 



File Management 




DosDupHandle 

Duplicates file or device handle 



DosFileLocks 

Locks or unlocks region of an open file 



DosNewSize 

Changes size of file 



DosQHandType 

Returns handle type 



DosRead 

Reads data from a file or device 



DosWrite 

Writes to file or device 



Misc. functions 




DosBeep 

Generates sound in Hertz/millisecond 



DosDevConfig 

Returns system hardware configuration 



DosGetMachineMode 

Returns flag indicating real or protected mode 



DosGetVersion 

Gets the operating-system version number 



DosSetSigHandler 

Installs a signal handler 



DosSetVec 

Installs exeption handlers 



DosTrueGetMessage 

Undocumented OS/2 function 


Listing of Important OS/2 Functions Available under DOS 


Listing 1 (memory.c) 


// cl /AL /Lp memory.c 
// bind286 memory 
// memory 

linclude <stdlib.h> 

#include <stdio.h> 

main() 

{ 

int i = 0; 

printf ("Al locating memory.. An"); 
while(l) 

if (malloc((unsigned)65512)) 

printf("Allocated 64K: %d blocks\n",++i); 
else 
break; 

printf("Ran out of available memory\n\n"); 
printf("Allocated %dK total An",i*64); 


/* End of File */ 


Example 1 


OS/2 Functions Under DOS 

A developer can perform true 
spawning, a feature of multitasking, via 
the OS/2 function DosExecPgmf). This 
function executes another program and 
is similar to the synchronous DOS func¬ 
tion exec, which also executes another 
program. DosExecPgmf), however, does 
not suspend the calling program until 
the program called has finished. Instead, 
it continues to run both programs 
simultaneously, otherwise known as 
asynchronous multitasking. 

To create multithreaded applications 
under DOS, one would use OS/2 func¬ 
tions such as DosCreateThread(), Dos- 
Exit(), DosEnterCritSec(), and Dos- 
ExitCritSecf). These functions create, 
destroy, and maintain threads. Dos- 
CreateThreadf) creates a new thread 
of execution, while DosExit () destroys 
an existing one. DosEnterCritSecO 
suspends all other threads in process so 
that some critical operation can be per¬ 
formed. A critical section requires the 
processor's full attention to perform 
some task, such as a disk access. Dos- 
ExitCritSec() resumes other threads 
that were in process previous to the 
DosEnterCritSecO call. 

One can ask what there is to be 
gained by using OS/2 functions under 
DOS. The answer is that DOS is small, 
fast, and basic. OS/2, on the other hand, 
is big, slow, and powerful. 

Ninety percent of all OS/2 functions 
are immediately accessible under DOS 
by simply linking in the OS/2 libraries. 
Nearly all of the other 10 percent of 
OS/2 functions, which are incompatible 
with DOS, are provided as part of 
286|DOS-Extender. The OS/2 functions 
not available under DOS are those that 
require direct service from the operat¬ 
ing system. These include the estab¬ 
lishment and control of sessions, pipes, 
and interprocess communication. Such 
capabilities are almost never needed by 
a DOS program, even one using all the 
complex features described here. If, 
however, your program requires one of 
these capabilities, 286|DOS-Extender al¬ 
lows you to write your own dynamic 
link library to support such function 
calls. Table 1 provides a listing of the 
important OS/2 functions available 
under DOS. 
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Debugging Your 
Protected Mode Program 

To debug a program created using 
Phar Lap's 2861 DOS-Extender, you must 
use the CodeView protected-mode 
debugger, which comes with the 
Microsoft C compiler and Macro As¬ 
sembler. The CodeView protected-mode 
debugger has special features to aid in 
the debugging of multithreaded applica¬ 
tions. 

Examples 

I've written three examples in C (List¬ 
ings 1, 2, 3, and 4) to illustrate the use 
of OS/2 functions to achieve multitask¬ 
ing, multithreading, and 16 megabytes 
of program code and data under DOS. 
The same programs could have been 
written in assembler. 


Listing 1, MEMORY. C, uses the stand¬ 
ard memory allocation function mal- 
loc(). Normally, mallocf) cannot allo¬ 
cate more than 640Kb of memory. 
Using Phar Lap's 2861 DOS-Extender, 
however, it can allocate up to 16 
megabytes of free memory. MEMORY. C 
can be compiled and run under DOS by 
anyone with Microsoft C 5.1 or 6.0 in¬ 
stalled with OS/2 libraries and Phar 
Lap's 2861 DOS-Extender. Follow the 
compilation directions at the top of 
each listing. All necessary libraries are 
supplied with Microsoft's C Compiler and 
MASM. 

CRITSEC.C (Listing 2) is an example 
of a multithreading program with a 
critical section. It uses the OS/2 function 
DosCreateThread() to start two 
threads which execute concurrently. 
The first thread continuously prints "1 * 
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Listing 2 (critsec.c) 


// cl /AL /Lp critsec.c 
// bind286 critsec 
// critsec 

Idefine INCL DOS 
Idefine 1NCL_SUB 
linclude <os2.h> 
linclude <malloc.h> 
Idefine STACK_SIZE 4096 

main() 

( 

char far *stkptr; 
void far threadl(); 
void far thread2(); 
unsigned threadID; 
int count; 
inti “ 400; 


stack pointer for threads */ 
prototype for thread 1 */ 
prototype for thread 2 */ 
thread ID number */ 
loop counter */ 
note frequency */ 


stkptr - (char far *)malloc(STACK_SIZE) + STACK_SIZE 
DosCreateThread(threadl, MhreadlD, stkptr); 
stkptr = (char far *) mall oc (STACKS IZE) + STACK_SIZE 
DosCreateThread(thread2, &threadID, stkptr); 

DosSleep(400L); /* let other threads run */ 

DosEnterCritSec(); /* stop other threads */ 
printf(”\nEntered critical section"); 
for(count=0; count <1; count++) ( 
for(; i < 800; i += 10) 

DosBeep(i,50); 
for(; i > 400; i -=5) 

DosBeepfi,50); 

1 

printf(" Exited critical sectionV); 
OosExitCritSecf); /* start other threads again 
DosSleep(400L); /* let other threads continue 

exit(0); /* exit all threads 


get stack space */ 
start thread one */ 
get stack space */ 
start thread two */ 


1 

void far threadl() ( 
while(TRUE) 

VioWrtTTY("l", 


void far thread2() 
while(TRUE) 
VioWrtTTY("2" 


/* End of File */ 


// beeping starts 


// beeping ends 

*/ 

*/ 

*/ 


1 . 0 ); 


threadl() 

continuously print “1“ 


1 , 0 ); 


/* thread2() */ 

I* continuously print "2" */ 


Example 2 
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while the second thread prints "2," so you end up seeing a 
mixture of the two. A critical section stops both threads and 
begins to beep. Normally a critical section might consist of a 
disk access or some other operation that cannot be inter¬ 
rupted. After the critical section is finished, the threads con¬ 
tinue to execute. 

The two programs, EXECPGM.C (Listing 3) and CHILD.C (List¬ 
ing 4), illustrate multitasking under DOS. Each program can be 
run as a standalone program, but because of the OS/2 call 
DosExecPgmO, CHILD.C is spawned by EXECPGM.C. Both EX¬ 
ECPGM.C and CHILD.C then continue to run concurrently. Since 
EXECPGM.C continuously prints "P" and CHILD.C prints "C,“ 
you will again see some of both. Thus, finally we can witness 
true asynchronous multitasking under DOS. 

The Future 

The answer for the future is not to divide the marketplace 
into strong supporters of different operating systems such as 
OS/2, UNIX, and PC-MOS/386. Rather, we should continue to 
use DOS, with its open architecture and command of the 
marketplace, as a base for extensions such as DOS extenders 
and Windows. □ 


DISASSEMBLERS ■■ 

Recover your source code from compiled 
applications with the following programs: 


UnClip, by Aladdin, for Clipper ’87. 

.$275.00 

OutFoxPro for unencrypted FoxPro 1.x... 
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OutFoxPro2 for unencrypted FoxPro 2.... 

.$149.95 

OutFOX for unencrypted FoxBASE+. 

.$149.95 

UEFOX+ unencrypts encrypted FoxBASE+. 

.$395.00 

deFOX for the early FoxBASE II. 

.$149.95 

dCRYPTR for AT dBASE 111+ RunTime+ 

.$149.95 

DECODE for AT dBASE II RunTime. 

.$149.95 
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11266 Barnett Valley Road 
Sebastopol, CA 95472-9255 


Monday thru Friday 


(707) 829-5011 


8 am to 5 pm Pacific 


Add $5.00 shipping and handling for each order. 

Overseas airmail add $5.00 for each program ordered. 
California residents add 7.5% sales tax. VISA & Mastercard accepted. 
PO from government agencies and D&B 1 or 2. 
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Listing 3 (execpgm.c) 


// cl /AL /Lp execpgm.c 
// bind286 execpgm 
// execpgm 

// execpgm.c - Example program to show how DosExecPgm Is used to create 
// a new process. This program starts CHILD.EXE as a new process. 

// By having this program print "P" and "CHILD.EXE" print "C", It Is 
// possible to see how the execution of both processes Is switched. 

extern unsigned far pascal DosExecPgm 
( 

char far *, 
unsigned, 
unsigned, 
char far *, 
char far *, 
struct Retlnfo far *, 
char far * 

); 

struct Retlnfo 
{ 

unsigned TermCode; 
unsigned RetCode ; 

i; 

Idefine ExecType 1 
Idefine PGM "child.exe" 

Idefine NMSG 1800 

unsigned far pascal DosSleep(unsigned long); 


//by its output 
//WORD input 
//WORD input 
//ASCIIZS input 
//ASCZ1IS input 
//DWORD output 
//ASCIIZ input 


-•'r a i i uujnaiiie 

FallObjNameLen 

ExecType 

->Arg 

->Env 

->RetInfo 

->PgmName 


main() 

{ 

struct Retlnfo Childlnfo; 
int i; 

printf("parent Started "); 

DosExecPgm(01,0,ExecType,01,01,&Ch1ldlnfo.PGM); 
for (1 * 1; i <=NMSG; i++){ 
printf("P"); 

DosSleep(O); 

) 

printf(" parent ended "); 

} 


/* End of File */ 


Example 3a 


Listing 4 (child.c) 

// cl /AL /Lp child.c 
// execpgm 

// Notice you do not need to bind this program unless 
// you want to run it as a stand alone. Execpgm is already 
// bound and therefore the processor is already in protected 
// mode by the time this program is reached. 

Idefine NMSG 1800 

unsigned far pascal DosSleep(unsigned long); 

main() 

< 

int i; 

printf(” child started “); 
for ( i = 1; i <= NMSG; i++) ( 
printf("C"); 

DosSleep(O); // Lets the DOS extender know to give 

) // time to other tasks (execpgm.c) 

printf(" child ended "); 

} 

/* End of File */ 


Example 3b 
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Windows Programming 



Building Free-Standing 
Control Buttons 

Alex Leavens 

Do you want to be able to create a text button that has something other 
than OK or CANCEL in it? Would you like to be able to place this button in your 
main window’s work area? This article will show you first how to create custom 
text buttons - buttons that can contain any text string you want. Then, when 
you've mastered custom text controls, you can move on to custom graphic 
controls, that is, buttons which contain not words, but pictures. The article also 
shows you how to respond to the various types of messages generated by 
these buttons and how to hook the buttons to a program action. In order to 
use the code presented here, you'll need Microsoft C 6.0 and the Microsoft 
Windows SDK. 

Building A Custom Text Button Control 

A typical Windows program contains a number of pushbuttons, often in the 
form of responses - such as “OK" or “Cancel" - to a query to the user. These 

queries are built using the MessageBoxf) API 
call, which will build the dialog box and the 
pushbuttons and will return the results of the 
user's action to your program. 

If you include pushbuttons in a dialog box, 
you must give each one a unique ID so that 
your program can identify it in the dialog box’s 
message loop. In this case, you must test the 
message ID to see if it matches that of your 
pushbutton, and then take the appropriate ac¬ 
tion if it does. 

In both the above cases, Windows will cre¬ 
ate the pushbuttons for you. In the case of the 
MessageBoxf) call, the buttons are created, 
handled, and destroyed without your knowing 
about it. In the case of the dialog box, the 
pushbuttons are created by the 
DialogBox() call; the pushbutton 
messages are handled by your 
dialog box routine; and the buttons 
are destroyed by the EndDialogO 
call. Although a little more work is 
involved, you are still able to use a 
pushbutton without learning the 
mechanics of creating one. 


Alex Leavens has more than 10 years of GUI design experience under numerous 
APIs, including both GEM and Windows. His most recent product is ICE/Works Professional, a high-end 
graphics resource editor for Windows. He can be reached at ShadowCat Technologies, Suite 741, 39120 
Argonaut Way, Fremont, CA 94538, (510)796-2239. 
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Listing 2 (grafbutn.c) 

/* 

* A sample application demonstrating the use of 

* a custom text button and a free-standing 

* graphic pushbutton in an application's main 

* window. 

* 

* Written by Alex Leavens, for ShadowCat Technologies 
*/ 

#include <WIND0WS.H> 
linclude "GRAFBUTN.H" 

/* ID of user-created buttons */ 

Idefine GRAPH_BUTTON ID 4001 
Idefine TEXT_BUTT0N_ID 4002 

/* defines for user-drawn buttons... */ 

Idefine N0F0CUS_N0FLAGS 0 

Idefine FOCUSJOFLAGS 1 

Idefine F0CUS_F0CUS 2 

Idefine DRAWALL 4 

Idefine $ELECT_N0FLAGS 8 

Idefine SELECT_SELECT 0x10 

Idefine SELECT_F0CUS 0x20 

Idefine SELECT_F0CUS_SELECT 0x30 

Idefine ALL_N0FLAGS 0x40 

Idefine ALL_F0CUS 0x80 

Idefine ALL SELECT 0x100 

Idefine ALL_FOCUS_SELECT 0x180 

/*- Function prototypes -*/ 

HWND CreateGraphButtonWindow(HWND); 

HWND CreateTextButtonWindow(HWND); 

BOOL DrawBitmap (HDC, int, int, HBITMAP, DWORD); 
void DrawGraphicButton(HWND, unsigned, WORD, LONG); 

WORD NEAR PASCAL GetDesiredButtonState(HWND, WORD, WORD); 

/*- Global variables -*/ 

HANDLE hlnst « 0; /* Handle to instance. */ 

HWND MainhWnd* 0; /* Handle to main window. */ 

HWND hClient = 0; /* Handle to window in client area.*/ 

FARPROC 1pClient= OL; /* Function for same. */ 

HANDLE hGraphButton; 

HANDLE hTextButton; 

/* WinMainO - Main windows routine */ 
int PASCAL WinMain(HANOLE hlnstance, 

HANDLE hPrevInstance, LPSTR IpCmdLine, 
int nCmdShow) 

{ 

MSG msg; 

hlnst = hlnstance; /* Saves the current instance */ 

if (IhPrevInstance) /* If already running */ 
if (!BLDRegisterClass(hlnstance)) 
return FALSE; 

MainhWnd = BLDCreateWindow(hlnstance); 
if (!MainhWnd) 
return FALSE; 

ShowWindow(MainhWnd, nCmdShow); 

UpdateWindow(MainhWnd); 

while (GetMessage(&msg, 0, 0, 0)) 

{ 

TranslateMessage(&msg); 

DispatchMessage(&msg); 

) 

return(msg.wParam); 


These buttons are very easy to use 
because Windows does most of the 
work. The ease of use comes at the 
cost of flexibility, however, since there's 
a limit to how much you can do with 
the predefined Windows buttons. If you 
want a button capable of more sophis¬ 
ticated behavior or with different text 
attributes, you'll have to create it your¬ 
self. 

This isn't as difficult as it sounds. In 
fact, creating and using free-standing 
text pushbuttons requires only three 
steps: 

• Create the pushbutton. 

• Display the pushbutton. 

• Monitor messages from the pushbut¬ 
ton and take some form of action 

when you receive a message from 

the pushbutton. 

The three steps are quite straightfor¬ 
ward, the most difficult being the first 
one - actually creating the pushbutton 
-which is done with a form of the 
CreateWindowf) API call, as shown in 
the sidebar. This form of Create- 
Uindow() will create a custom text con¬ 
trol - a pushbutton - for you. The cus¬ 
tom text control is really a specialized 
form of window, a free-standing push¬ 
button. One important note about the 
form of the CreateUindow() call used 
here is that you must assign a unique 
ID to your pushbutton when creating it. 
This will be especially true if you create 
more than one pushbutton. 

Step 2, displaying the pushbutton, is 
free; since the button was created with 
the styles US CHILD and US_VISIBLE, 
Windows will automatically display it 
when you display your program's main 
window. 

Step 3, monitoring and responding to 
the pushbutton(s) is done via the 
WM_COMMAND message: each time a 
pushbutton is released, a UM_COMMAND 
message is generated. Since other con¬ 
trols (menus and accelerators) also 
generate UM_COMMAND messages, it’s im¬ 
portant to be able to distinguish be¬ 
tween them. 

When a pushbutton generates a 
WM_COMMAND message, its ID (which was 
assigned in the CreateUindow() call, 
noted above) is passed along in the w- 
Param variable. When your program 
receives a message from the pushbutton, 
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Listing 2 —Cont’d 


/* WINDOW PROCEDURE FOR MAIN WINDOW */ 
long FAR PASCAL 

BLDMainWndProc(HWND hWnd, unsigned message, WORD wParam, 

LONG IParam) 

{ 

switch (message) 

( 

case WM_DRAWITEM: /* Owner draw button message */ 
DrawGraphicButton(hWnd, message, 
wParam, IParam); 
break; 

case WM_CREATE: 

return DefWindowProc(hWnd, message, wParam, IParam); 
case WM_SETFOCUS: /* notification of focus change */ 
return DefWindowProc(hWnd, message, wParam, IParam); 
case WM_DESTROY: 

PostQuitMessage(O); 

return DefWindowProc(hWnd, message, wParam, IParam); 
break; 

case WM_COMMAND: /* command from the main window */ 
switch(wParam) 

f 

case IDM_Quit: 

PostMessage(hWnd, WM_CL0SE, 0, OL); 
return DefWindowProc(hWnd, message, 
wParam,IParam); 

break; 

case GRAPH_BUTTON_ID: 

MessageBox(hWnd,“You clicked my button!", 
"Graphic button example", 

MBJCONEXCLAMATION | MB_0K); 
break; 

case TEXT_BUTTONJD: 

MessageBox(hWnd,"You clicked my button! 1 ', 

"Text button example", 

MBJCONEXCLAMATION | MB OK); 
break; 
default: 

return DefWindowProc(hWnd, message, 
wParam, IParam); 

) 

break; 

default: 

return DefWindowProc(hWnd, message, wParam, IParam); 

) 

return FALSE; /* Returns FALSE if processed */ 


/* BLDRegisterClass() - Registers class for main window */ 


BOOL 

BLDRegisterClass(HANDLE hlnstance) 

! 

WNDCLASS WndClass; 


WndClass.style 
WndClass.1pfnWndProc 
WndClass.cbClsExtra 
WndClass.cbWndExtra 
WndClass.hlnstance 
WndClass.hlcon 
WndClass.hCursor 
WndClass.hbrBackground 

WndClass.1pszMenuName 
WndClass.IpszClassName 


- 0; 

= BLDMainWndProc; 

- 0; 

= 0 ; 

= hlnstance; 

= LoadIcon(NULL,"GRAPHIC"); 

* LoadCursor(NULL,IDC_ARR0W); 
= CreateSolidBrush( 
GetSysColor(COLORJIINDOW)); 

- "GRAFBUTN"; 

= “GRAFBUTN"; 


return RegisterClass(&WndClass); 

) 
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• free tech support 
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Listing 2 — Cont’d 

/* BLDCreateWindowQ - Creates the main window */ 


HWND 

BLDCreateWindow(HANDLE hlnstance) 

f 

HWND hWnd; /* window handle */ 

int coordinate[4]; /* Coordinates of main window */ 

coordinate[0]=CW_USEDEFAULT; 

coordinate[l]=0; 

coordinate[2]=CW_USEDEFAULT; 

coordinate[3]=0; 


hWnd = CreateWindow( 

"GRAFBUTN", /* window class registered earlier */ 
“Graphic Picturebutton Example", /* caption */ 
WS_0VERLAPPED | WS_THICKFRAME | 

WS SYSMENU WS MINIMIZEBOX 


WS_MAXIMIZEBOX, / 
CW_USEDEFAULT, / 
0 , / 
CW_USEDEFAULT, / 
0 , / 
0 , / 
0 , / 
hlnstance, / 
(LPSTR)NULL); / 


window style 
x position 
y position 
width 
height 

parent handle 
menu or child 
instance 


7 

7 

7 

7 

7 

*/ 

ID*/ 

*/ 


’ additional info */ 


hGraphButton ■ CreateGraphButtonWindow(hWnd); 

hTextButton ■ CreateTextButtonWindow(hWnd); 

if (hGraphButton && hTextButton) 
return hWnd; 

else 

return NULL; 


/* CreateTextButtonWindowO 

* Creates a free-standing child window 

* button in a program's main window. 

*/ 


HWND CreateTextButtonWindow(HWND hWnd) 

{ 


HWND 

deskhWnd, 

hButton; 

HOC 

deskhDC; 


int 

gl_hchar. 

gl_wchar; 


TEXTMETRIC sysText; 


/* Get system metrics so that we can size the button properly. 
*/ 

deskhWnd = GetDesktopWindowO; 
deskhDC = GetDC(deskhWnd); 


/* Grab the size of text cells... 

*/ 

GetTextMetrics(deskhDC, (LPTEXTMETRICj&sysText); 
gl_wchar = sysText.tmAveCharWidth; 
gl_hchar = sysText.tmHeight; 

ReleaseDC(deskhWnd, deskhDC); 

hButton = CreateWindow( 

"BUTTON", 

(LPSTR)“My Button", 

BS_PUSHBUTT0N | 

WS_CHILD | 

WS_VISIBLE, 

60, 

20 , 

11 * gl_wchar, 

gl_hchar + gl_hchar / 3 + 1, 
hWnd, 

TEXT_BUTTON_ID, 

hlnst, 

NULL); 


it can take whatever action you specify. 
In the sample program I've provided, 
pushing the pushbutton will display a 
small dialog box. 

There is an important point about 
monitoring messages from text push¬ 
buttons which may not be immediately 
obvious: your program will receive a 
M_COMMAND message from the button 
only if the user releases the mouse but¬ 
ton while the cursor is still inside the 
text pushbutton. 

If the user presses the mouse button 
down with the cursor inside your push¬ 
button and, while still holding down the 
mouse, drags the cursor outside the 
pushbutton, then releases the button, 
your program will not receive a 
UM_C0MMAND message. This part of the 
functionality of the pushbutton is auto¬ 
matically provided by the control itself 
- no work on your part is required. 

When The Application 
Is Closed 

The free-standing button that you've 
created is really a child-window of your 
program’s main window. How should 
your program deal with the button 
when the main window is iconified, ex¬ 
panded, de-iconified, etc.? In most 
cases, you pass the message to Def- 
HindowProc(), and the behavior of the 
pushbutton is handled automatically. 
Furthermore, since this is a child win¬ 
dow, you do not need to destroy it ex¬ 
plicitly when the application is closed; 
Windows will do it for you. 

Building A Custom Graphic 
Button Control 

It's important to have a good under¬ 
standing of the processes involved in 
creating a custom text pushbutton be¬ 
cause the creation of a custom graphic 
pushbutton builds on that knowledge. A 
custom graphic pushbutton - or PIC¬ 
TUREBUTTON - has a picture (bitmap) in 
it, rather than text. The picture can rep¬ 
resent anything; typically, picturebut- 
tons are used in creating graphical tool 
palettes. 

To create and use a picturebutton, 
you’ll perform the same steps as for a 
text pushbutton: 

• Create the picturebutton. 

• Display the picturebutton. 
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Listing 2 — Cont’d 


if (IhButton) 

{ 

DestroyWindow(hWnd); 
return FALSE; 

) 

return hButton; 


/* CreateGraphButtonWindowO - Creates a free-standing 
* child window button in a program's main window. 
*/ 

HWND CreateGraphButtonWindow(HWND hWnd) 

{ 

HWND hButton; 


hButton = CreateWindowCBUTTON", (LPSTR)"My Button", 
BS_OWNERDRAW | WS_CHILD | WS_VISIBLE, 

20, /* x offset */ 

20, /* y offset */ 

32, /* x size in pixels */ 

32, /* y size in pixels */ 

hWnd, GRAPH_BUTTON_ID, hlnst, NULL); 
if (IhButton) 

( 

DestroyWindow(hWnd); 
return FALSE; 

) 

return hButton; 


/* 

* DrawBitmapO 

* Given a handle to a bitmap, and a device 

* context, this routine will draw the bitmap 

* into that device context at the requested 

* offset locations. 

* 

* Returns: TRUE - bitmap sucessfully drawn 

* FALSE - bitmap was not drawn sucessfully 
*/ 


BOOL 

DrawBitmap (HDC hDC, 

int x, 

int y, 

HBITMAP hbm, 

DWORD rop) 

{ 

HDC hMemoryDC; 

BITMAP bm; 

BOOL f; 

HBITMAP bmHand; 


/* Destination DC */ 

/* X offset */ 

/* Y offset */ 

/* Handle to source bitmap */ 
/* Raster OP to perform */ 


if (!hDC || !hbm) /* If either handle is bad, punt */ 
return FALSE; 


/* Before we can blit the bitmap, it has to be 

* selected into a device context compatible 

* with the destination. So first, we need to 

* create the compatible DC. 

*/ 

hMemoryDC = CreateCompatibleDC(hDC); 

/* Select desired bitmap into the memory DC we 

* just created. Also remember the old bitmap 

* handle that used to be in the DC, so that we 

* can restore it after we're done. 

*/ 

bmHand = SelectObject(hMemoryDC, hbm); 
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Listing 2 — Cont’d 

/* Get information about the bitmap, so that we 

* can blit it properly. 

*/ 

GetObject(hbm, sizeof(BITMAP), (LPSTR)Sbm); 

/* Everything's set up--we can now blit the 

* image into the destination DC. 

*/ 

f ■ BitBlt(hDC, /* Destination DC */ 

x, /* Destination x offset (if any) */ 

y, /* Destination y offset (if any) */ 

bm.bmWidth,/* Width of source bitmap */ 
bm.bmHeight,/* Height of source bitmap */ 
hMemoryDC,/* Source DC */ 

0, /* Source x offset (none) */ 

0, /* Source y offset (none) */ 

rop); /* Copy the bitmap... */ 

/* Now select the old bitmap handle back into the 

* memory DC. (Failure to do this will cause a 

* small piece of Windows resource to be lost 

* until re-boot time.) 

*/ 

SelectObject(hMemoryDC, bmHand); 

/* Delete the memory DC so that we're not 

* using up system resources. 

*/ 

DeleteDC(hMemoryDC); 

/* Return status of the BitBlt() call. */ 
return f; 


/* DrawGraphicButton() 

* Draws a graphic bitmap button on the screen. 

* Returns; Nothing 
*/ 


void 

DrawGraphicButton(HWND hWnd, unsigned message, WORD wParam, 


LPDRAWITEMSTRUCT lpDraw; /* Info about thing to draw */ 
WORD flags; /* Info about button state */ 

HBITMAP bmButton; /* Handle to bitmap button */ 

lpDraw - (LPDRAWITEMSTRUCT)lParam; 

/* If control is not the right type, punt. 

* (This should never happen, right?) 

*/ 

if (lpDraw->CtlType != ODT_BUTTON) 
return; 


/* Get button state */ 

flags * GetDesiredButtonState(hWnd, 

lpDraw->itemAction, lpDraw->itemState); 
switch(flags) 

( 

case ALL_SELECT: 
case ALL~FOCUS_SELECT: 
case SELECT SELECT: 
case SELECT_FOCUS_SELECT: 

bmButton = LoadBitmap(hInst, “DOWNFACE”); 
break; 
default: 

bm8utton = LoadBitmap(hInst, "UPFACE"); 

) 

DrawBitmap(lpDraw->hDC, 0, 0, bmButton, SRCCOPY); 


• Monitor messages from the pic- 

turebutton and take some form of 

action when you receive a message. 

The first step, creating the pic- 
turebutton, involves a call to Create- 
Uindowf) very similar to the one used 
to create a text pushbutton. The dif¬ 
ference is that instead of using the class 
BS_PUSHBUTTON, you’ll use the class 
BSJDUNERDRAW. The other parameters 
are the same. 

As the name inplies, the class 
BS_OWNERDRAW gives the owner of the 
button - your application - complete 
responsibility for drawing whatever is to 
appear there. This makes steps 2 and 3 
considerably more involved. Where 
before you simply passed the message 
along to DefWindowProc() and Win¬ 
dows took care of the drawing, now 
you must do it yourself. 

You’re not completely on your own, 
however; when an OWNERDRAM button 
needs to be drawn, Windows sends 
you a wm_drauitem message. The l- 
Param of this message is a pointer to a 
DRAWITEMSTRUCT, which contains a great 
deal of useful information. In particular, 
the DRAWITEMSTRUCT contains a handle 
to the device context of the window 
which needs to be redrawn. You can 
use this handle in any API calls which 
require an hDC. 

Although this article focuses on 
using bitmaps to create picturebuttons, 
once you have the picturebutton’s DC 
you can use any method available in 
the Windows API to draw the button. 
You can draw lines, circles, rectangles, 
and virtually anything else into the pic- 
turebutton via its DC. 

An important point to remember, 
regardless of the drawing method, is 
that the picturebutton’s DC starts with 
the point (0, 0) as the upper left corner. 
Since the picturebutton is a child win¬ 
dow of your program’s main window, 
it's easy to assume that the 
picturebutton's visible area would start 
at the offset where it was placed when 
created. This is most assuredly not the 
case. Since the picturebutton is a win¬ 
dow in its own right, it doesn’t matter 
where you create and place it - the 
picturebutton’s visible area will always 
start at (0, 0). If you do add an offset to 
the picturebutton’s DC, you’ll probably 
cause the image to be placed in a por¬ 
tion of the picturebutton's window 
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Listing 2 — Cont’d 


y*************************** 

* 

* GetDesiredButtonStateO 

* Returns a value which indicates the desired end result 

* of a button press on an owner-drawn button. 

* 

* Params: 

* hWnd - window handle 

* itemAction - action taken 

* itemState - desired end state 

* 

* Returns: 

* Flag setting 

* 

* Assumptions: 

* None 

*/ 

WORD NEAR PASCAL 

GetDesiredButtonState(HWND hWnd, 

WORD itemAction, 

WORD itemState) 

{ 

WORD 1 Flags; /* Local flag value */ 

/*.*/ 

1 Flags = N0F0CUS_N0FLAGS; 

if (itemAction & ODA_FOCUS) 

( 

if (itemState & 0DS_F0CUS) 

1 Flags = FOCUS_FOCUS; 

else 

1 Flags = F0CUS_N0FLAGS; 

) 

if (itemAction & ODA_SELECT) 

( 

if (itemState & ODS_FOCUS) 

1 Flags |= SELECT_FOCUS; 
if (itemState & ODS_SELECTED) 

1 Flags |= SELECT_SELECT; 

) 

if (itemAction & ODA_DRAWENTIRE) 

( 

1 Flags = ALL_NOFLAGS; 
if (itemState & 0DS_F0CUS) 

1 Flags |= ALL_F0CUS; 
if (itemState & ODSJELECTED) 

1 Flags |= ALL_SELECT; 

) 

return (1 Flags); 

) 

/* End of File */ 
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A Variation On Createblindow () 


The CreateUindow() call shown here is a variation 
on the one that you use to create the main window of 
your program, but with a number of important dif¬ 
ferences. 


control Handle = 
CreateWindow( 
“BUTTON", 

“My Control", 

BS_PUSHBUTTON 

WS_CHILD | 

WS_VISIBLE, 

xOffset, 

yOffset, 

btnWidth, 

btnHeight, 

hWnd, 

BUTT0N_ID, 

hlnst, 

NULL 

); 


/* Button class */ 

/* Name of button */ 

/* Window styles for */ 

/* this button */ 

/* x offset */ 

/* y offset */ 

/* Width of button */ 

/* Height of button */ 

/* Parent window handle */ 
/* User defined ID */ 

/* Application's instance */ 


AFTER DARK CONTEST 

IffV 


GRAND PRIZE 
0 , 000 ^-^ 
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COMPUTER ARTIST CATEGORY 

First Prize: $2,500 MacConnection or PC Connection Shopping Spree 
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Winners immortalized in future versions of After Dark! 
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The deadline is April 1st, so call today! 
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SYSTEMS 
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The first difference is in the class name of the win¬ 
dow you are creating. By using the BUTTON string for 
the class name, you are telling Windows that you 
want to create a standard Windows button. 

The second difference is in the window name-, for a 
button class, this actually defines the text that will ap¬ 
pear inside the button. 

The third parameter defines the style(s) that the 
control will have. In order to receive messages from 
the control, you must use the BS_PUSHBUTTON style. 
Using the US_CHILD style tells Windows to make the 
control a child window of your main window; this 
means that Windows will automatically pass any mes¬ 
sages for the control to your main message loop. The 
US_VISIBLE style means that when you create and 
show your main window, Windows will automatically 
create and show this control window. 

The next two parameters define the x and y posi¬ 
tion where your pushbutton control will be placed in 
the main window. Windows uses the upper left corner 
of the main window as a reference point; using 20, 20 
as the x and y offsets would put the pushbutton 20 
pixels down and 20 pixels to the right of the upper left 
corner of the client area of your main window. 

btnUidth and btnHeight control the width and 
height of the button, respectively. Listing 1 shows how 
you can use the GetTextMetrics() call to ensure that 
your button will be properly sized, regardless of which 
resolution the end user runs Windows in. 

The hUnd parameter is the window handle of the 
parent window. It's important to make sure that you 
are passing in the window handle of your main win¬ 
dow. If you don’t, you won't receive any of the mes¬ 
sages for the button control. 

The next parameter is the ID value that you want 
to assign to the control. This can be any integer value 
that you want, as long as you haven't associated the 
value with some other window or control. This ID value 
is what you'll use to recognize messages to this con¬ 
trol. 

The hlnst parameter is the instance of your ap¬ 
plication which is creating the control; if you can run 
multiple copies of your application, then this handle 
lets Windows distinguish which instance is creating the 
control. 

The final parameter is a long pointer that is passed 
through the IParam value of the UM_CREATE message. 
For button controls, you can set this value to be NULL. □ 
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Listing 1 (grafbutn.h) 

/* 

* by Alex Leavens, for ShadowCat Technologies 

/* Constants for error message 

strings */ 

Idefine BLD CannotRun 

4000 

Idefine BLD CannotCreate 

4001 

Idefine BLD CannotLoadMenu 

4002 

Idefine BLD CannotLoadlcon 

4003 

Idefine 8LD_CannotLoadBitmap 

4004 

BOOL BLDRegisterClass(HANDLE); 
HWND BLDCreateWindow(HANDLE); 


Idefine IDM_Quit 

4000 

/* End of File */ 



; written by 

Listing 3 (grafbutn.def) 

Alex Leavens, for ShadowCat Technologies 

NAME 

GRAFBUTN 

DESCRIPTION 

'GRAFBUTN' 

EXETYPE 

WINDOWS 

STUB 

'WINSTUB.EXE' 

DATA 

MOVEABLE MULTIPLE 

CODE 

MOVEABLE DISCARDABLE PRELOAD 

HEAPSIZE 

1024 

STACKSIZE 

5120 

EXPORTS 

BLDMainWndProc 


Listing 4 (grafbutn.rc) 


* Written by Alex Leavens, for ShadowCat Technologies 
*/ 

linclude <WIND0WS.H> 

#include “GRAFBUTN.H" 


UPFACE BITMAP UPFACE.BMP 

DOWNFACE BITMAP DOWNFACE.BMP 

GRAPHIC ICON GRAPHIC.ICO 

/★★a***************************************************** j 

/* Resource code for menus */ 

^★*******************************************************^ 

GRAFBUTN MENU 
BEGIN 

POPUP “File" 

BEGIN 

MENUITEM "Quit", IDM_Quit 
END 
END 


j********************************************************j 

I* Resource code for error message strings */ 

^★★★★★♦★★★★★★★★★★★★Hr*************************************^ 

STRINGTABLE 

BEGIN 

BLD_CannotRun "Cannot run " 

BLD_CannotCreate "Cannot create dialog box " 

BLD_CannotLoadMenu "Cannot load menu * 

BLD_CannotLoadIcon "Cannot load icon " 

BLD_CannotLoadBitmap "Cannot load bitmap " 

END 


which is being clipped, with the result that nothing at all will 
show up! 

For the purposes of drawing a picturebutton, bitmaps are 
almost the ideal tool. They’re compact (a 32x32 16-color bit¬ 
map occupies only a bit more than 512 bytes of space in the 
.exe file), and they're easy to manipulate. Since Windows al¬ 
ready supports moving and copying bitmaps (via the BitBlt() 
and StretchBlit() calls), it’s fairly simple to copy a bitmap 
into a window handle. 

The first step is to get a handle to the bitmap, so that you 
can manipulate it. This is accomplished via the LoadBitmapf) 
call (as shown in Listing 1), which returns a handle to the 
bitmap. Don’t just assume that the handle to the bitmap will 
be valid; LoadBitmapO will return NULL if it was unable to 
load the requested bitmap. 

With the hDC of the destination window and a handle to 
the source bitmap, you have all the pieces you need to copy 
the image into the picturebutton. The routine DrawBitmapO , 
in Listing 1, is actually responsible for the transfer of the 
image. 

DrawBitmapO first ensures that both the hDC and the 
HBITMAP being passed in are not NULL. Next, it creates a 
device context compatible with the destination DC- this com¬ 
patible DC is used as the DC for your source bitmap. 

After the DC has been created, the BitBltf) call selects 
the source bitmap into it and copies it. Note how, just before 
the bl i t, GetObject() is called in order to obtain the size of the 
source bitmap. Once the bitmap has been copied, the bitmap 
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tation, sample program and source code. Only $199.95 
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originally in the DC is selected back in, 
and then the DC is deleted. 

It is important to reselect the 
original bitmap handle before deleting 
the DC: failure to do so will waste valu¬ 


able system resources. Every DC created 
via a CreateCompatibleDCO call has in¬ 
itially a single-pixel, monochrome bit¬ 
map selected in it. If this bitmap is not 
selected back into the DC before you 


delete the DC, then that single-pixel bit¬ 
map cannot be removed from the sys¬ 
tem resource list, if this happens often, 
the result will be a great many single¬ 
pixel bitmaps cluttering up memory and 
slowing performance down. The only 
recourse at this point is to reboot - 
hardly a solution that will please users 
of your application. 

Now that you can draw into the DC 
of a picturebutton, the next step is to 
determine what kind of image should 
be drawn there in response to a given 
message (it wouldn’t be helpful to dis¬ 
play the same image for both a down 
and an up button). 

Fortunately, the information needed 
for determining how the button should 
look is also passed along in the 
DRAUITEMSTRUCT, in the fields item- 
Action and itemState. The routine 
GetDesiredButtonState() takes this 
information and transforms it into a flag 
which you can use to determine how 
to draw the button - either up or 
down. 

Drawing the button up or down is 
simply a matter of loading different bit¬ 
maps; one representing up and one 
down. Even though you are responsible 
for the actual drawing of the up and 
down states, Windows will still handle 
the logic that's required when the user 
moves the mouse off the button 
without releasing the click. 

Now that you have all the pieces, 
you can put them together. The listings 
do just that; they draw a picturebutton 
in one of two states and display an 
alert box when you click on the button. 
Included are Listing 1, GRAFBUTN.H, the 
header file; Listing 2, GRAFBUTN.C, the 
program itself; Listing 3, GRAFBUTN.DEF, 
module definition file for the .exe file-, 
Listing 4, GRAFBUTN.RC, the resource 
definition file; and the makefile for 
GRAFBUTN.EXE. (Included on the code 
disk are also DOUNFACE.BMP, the pressed 
bitmap for the graphic button-, UP- 
FACE. BMP, the unpressed bitmap for the 
graphic button; and GRAPHIC. ICO, the 
icon for the demo program.) 

By using the code shown, you can 
build your own picturebutton and hook 
it to whatever functionality you'd like. 
By doing so, you'll be providing the end 
user with a level of feedback that 
would be difficult to achieve using a 
simple text pushbutton. □ 



Listing 5 (makefile) 

f 

# Microsoft C v6.00ax makefile for grafbutn.exe 

CFLAGS- 

-Gcsw2 -Od -W3 -Zp -Zi -EM 

IWhere: 


# -Gcsw2 - Pascal-style functions, no stack 

# 

checking, generate Windows epilog 

# 

and prolog, use 80286 instructions. 

# -Od 

- Turn off optimizations (cause they 

# 

sometimes cause bugs). 

1 -W3 

- Warning level 3 

# -Zp 

- pack structures on byte boundaries 

f -Zi 

- generate debugging information 

# -EM 

- Use DOS-extended version of compiler 

MODEL 

=s 

WLIBS 

= libw $(MODEL)libcew 

APPNAME 

=grafbutn 

OBJ 

=J(APPNAME).obj 

.rc.res 

rc -r $*.rc 

$ (APPNAME).exe ; $ (OBJ) $ (APPNAME).res makefile $ (APPNAME).def 


link $(LFLAGS) $ (OBJ),,, $ (WLIBS) {(LIBS),{(APPNAME).def 
rc $ (APPNAME).res {(APPNAME).exe 

$ (APPNAME).res ; $(APPNAME).rc 
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More About Set Types 


In my last column ("Using Built-in Set Types,” 2.12, December, 1991), my wife, 
Nancy, and I explained the built-in set types of Pascal and Modula-2. We focused on 
the abstract properties of sets without concern for implementation details. This 
month, I'll show you how Pascal and Modula-2 represent sets and how they 
generate code to implement set operations. Understanding the implementation 
helps you judge whether sets are appropriate for a particular application. It also 
enables you to implement your own set operations in languages like C and C++ that 
don't have built-in set types. 

Sets As Bit Arrays 

Pascal and Modula-2 represent sets as sequences of bits, called bit arrays or bit 
vectors. For a given set, each bit in the bit array corresponds to an element in the 
set’s base type. The value of a particular bit is 1 if the corresponding element is in 
the set, and 0 if not. For example, the set 

var 

s : set of 0 .. 9; 

occupies ten bits, numbered 0 through 9. The assignment 
s := [2, 5, 8]; 

sets bits 2, 5, and 8 of s to 1, and all other bits to 0. 

For sets of enumeration or character types, the bit positions correspond to the 
ordinal values of the set elements (the ordinal value is the underlying integer value). 
For example, a set of months defined as 

type 

month = (JAN, FEB, MAR, APR, MAY, JUN, 

JUL, AUG, SEP, OCT, NOV, DEC); 
month set = set of month; 


Dan Saks Dan Saks is the owner of Saks & Associates, which offers consulting and training in 

C, C++ and Pascal. He is also a contributing editor of The C Users Journal. He serves as 
secretory of the ANSI C++ committee and is a member of the ANSI C committee. 
Readers can write to him at 287 W. McCreight Ave., Springfield, OH 45504 or by email 
at dsaks@wittenberg.edu. 





























requires 12 bits numbered 0 (for JAN) through 11 (for DEC). A 
constant set of months like 


Listing 1 

{* 

* view a set as a byte array 
*} 

type 

month = (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, 
SEP, OCT, NOV, DEC); 
month_set ■ set of month; 
byte_array = array [0 .. sizeof(month_set)-l] 
of byte; 
var 

thirty_days : month_set; 
p : A byte_array; 
i : integer; 

begin 

thirty_days := [APR, JUN, SEP, NOV]; 
p addr(thirty_days); 
for i := 0 to sizeof(p A )-l do 
writeln(p A [i]:2); 

end. 

( End of File ) 


const 

thirty_days : month_set 
= [APR, JUL, SEP, NOV]; 

has a 2 in bits 3, 6, 8, and 10, and 0 everywhere else. 

The range of ordinal values for character types varies 
among systems and compilers. For Pascal and Modula-2 com¬ 
pilers on the PC, the range is typically 0 to 255. Using these 
compilers, a set such as 


* Decoding Your Mailing Label * 


The numbers on your mailing label appear as: 

10000 #07.1 08.3 

The first number is your account number. The 
second set of numbers represents the issue you just 
received (in <volume>.<issue> format) and the third 
set represents the issue with which your subscription 
expires. The example was mailed to account number 
10,000, affixed to vol. 7, no. 1, and expires with vol. 8, 
no. 3. 

NOTE: If the last two sets of numbers match, 
this is the last issue of your subscription. To avoid 
missing any issues, contact us today. 

For any questions about your subscription call us 
at (913) 841-1631. Having your mailing label handy 
will speed up the transaction. Thanks! 

R&D Publications 

1601 W. 23rd. St., Ste. 200 
P.O. Box 3127 

Lawrence, KS 66046-0127 
(913) 841-1631 
FAX (913) 841-2624 


var 

lower : set of char; 
occupies 256 bits, and the assignment 
lower := ['a' .. 1 z 1 ]; 

sets bits 97 through 122 to J(using ASCII, ord('a') is 97 and 
ord('z') is 122). 

The PCs smallest addressable unit is an eight-bit byte, so 
the number of bits actually allocated for a set is the number 
of elements in the set’s base type rounded up to the nearest 
multiple of eight. For example, a set of months requires only 
12 bits, but actually occupies two bytes (16 bits). The excess 
bits are set to 0 and left unused. 

When viewing a bit array as a sequence of bytes, you refer 
to each bit by its byte offset and its relative bit position. The 
first byte of the array is at offset 0. The bits in a byte are 
numbered from 0 to 7, where the least significant (rightmost) 
bit is 0. Figure 1 illustrates this byte-oriented view for a set of 
months. For example, MAY’S ordinal value is 4, so its cor¬ 
responding bit in the set is at bit 4 of byte 0. NOV’s ordinal 
value is 10, so NOV's bit is at bit 2 of byte 1. 

The Turbo Pascal program in Listing 1 demonstrates a tech¬ 
nique for viewing a set as a sequence of bytes. It uses the 
Turbo Pascal addr function to copy the address of set thir- 
ty_days into a pointer, p, that points to an array of bytes. The 
for loop displays each byte of the array referenced by p. In 
particular, the statement 

writeln(p A [i]:2); 

writes the ith byte of the array referenced by p as a 2-digit 
decimal integer. Also, note how I used the sizeof function in 
the type definition for byte_array to make the size of a 
byte_array the same as the size of a montb_set. 

Implementing Set Operations 

The byte-oriented view of bit arrays provides a conceptual 
model for implementing set operations. Operations on entire 
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sets, such as assignment (;=) or comparison (=), operate on 
each set a byte at a time. For example, if si and s2 are sets 
of the same type, then the assignment 

si := s2; 

is simply a byte-by-byte copy from s2 to si. The assignment 
s := []; 

empties set s by storing 0 into each byte of s. 

Operations on an individual set element use bitwise-or and 
bitwise-ond operators to turn the specified bit on or off or to 
test the bit's value. For example, if s is a month_set, then 

incl(s, NOV); (* Modula-2 *) 

or 

s := s + [NOV]; n { Pascal ) 

adds the element NOV to s. NOV' s ordinal value is 10, so adding 
NOV to s stores a 1 in bit 2 of byte 1 of s (of course, NOV may 
already be in the set, so adding the element may have no 
effect). The code generated by the compiler creates a one- 
byte mask that is 0 everywhere except for bit 2 (NOV’ s bit 
position), and then logically ors the mask into byte 1 (NOV' s 
byte). The or forces bit 2 on, and leaves all the other bits 
unchanged, as illustrated by Figure 2. 

The functions in Listing 2 demonstrate byte-oriented im¬ 
plementations for selected set operations. Type bit set is a 
set of integers in the range 0 to BITS_PER_SET-1. The con¬ 
stant BYTES_PER_SET defines the number of bytes in a bitset, 
computed by dividing BITS_PER_SET by BITS_PER_BYTE and 
rounding the result up to the nearest integer. 

Procedure empty empties a set by storing a 0 into each 
byte of the set. Turbo Pascal lets you replace the for loop 
with a library function call: 

fillchar(s, sizeof(s), 0); 

The incl procedure adds a single element to a set using the 
algorithm described above. The statement 

offset := e div BITS_PER_BYTE; 

computes the byte offset for element e (div returns the in¬ 
teger-valued quotient of the division). For example, if e is 25, 
then e div 8 is 3. 

incl generates the bit mask in two steps. The statement 
bitpos := e mod BITS_PER_BYTE; 

computes the bit position within the byte (mod returns the 
integer-valued remainder of the division). For example, if e is 
25, then e mod 8 is 1. The next statement, 

mask := 1 shl bitpos; 






Figure 2 
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computes the bit mask by shifting a single bit left (and filling 
with 0’s) until the 1 is in the correct bit position. Remember, 
bit 0 is the least significant bit, so if bitpos is 0, the 1 isn't 
shifted at all. If bitpos is 1, the single bit is shifted once, and 
so on. By the definition of the mod operator, bitpos cannot 
exceed BITS_PER_BYTE-1, so there's no danger of shifting the 
mask bit beyond the most significant bit in a byte. The last 
statement in the incl procedure, 

s[offset] := s[offset] or mask; 

actually adds the element to the set. 

The version of incl in Listing 2 computes the byte offset 
and bit position using expressions that work for any value of 
BITS_PER_BYTE. The code is a little more general, but at a 
price, div and mod are expensive operations, so the generated 
machine code is longer and slower than necessary. In practice, 
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compilers know that there are eight bits in a byte, and use 
this knowledge to generate tighter code. When computing 
byte offsets and bit positions, compilers actually implement 

offset := e div 8; 

bitpos := e mod 8; 

as 

offset := e shr 3; 

bitpos := e and 7; 

replacing the expensive div and mod operators with the rela¬ 
tively cheap shift-right and bitwise-and operators. These 
replacements compute the same results in less space and 
time. 

The function member in Listing 2 determines whether an 
element is a member of a set. That is, when a compiler en¬ 
counters a statement like 


if e in s then 

it generates code that is equivalent to 
if member(e, s) then 

member uses the eight-bit specific computations for offset 
and bitpos. Otherwise, the algorithm for member is identical 
to incl until the last line. Whereas incl sets a bit in the set, 
member tests if that bit is set. 

The intersection of two sets A and B is the set of elements 
that are in both A and B. Thus, the intersect function inter¬ 
sects two sets by and'mg the corresponding bytes in each set. 
The implementation for the union operator (not shown in List¬ 
ing 2) is identical to intersection, except it uses the or 
operator instead of and. 

Not all compilers translate set operations into runtime 
function calls. Some compilers generate the code inline. In 
other words, some compilers compile a statement like 


Listing 2 


const 

BITS_PER_SET = 30; 

BITSPERBYTE = 8; 

BYTES_PER_SET = (BITS_PER_SET + BITSPERBYTE - 1) 
div BIT$_PER_BYTE; 

type 

bitset « array [0 .. BYTES_PER_SET] of byte; 

1 * 

* Empty set s. This is equivalent to s := []; 

*1 

procedure empty(var s : bitset); 
var 

i : integer; 

begi n 

for i :- 0 to sizeof(s) - 1 do 
s[i] :=■ 0; 

end; 

(* 

* Add element e to set s. This is equivalent to 

* s := s + [e]; 

procedure incl(var s : bitset; e : integer); 
var 

bitpos, offset : integer; 
mask : byte; 

begin 

offset := e div BITS_PER_BYTE; 
bitpos := e mod BITSPERBYTE; 
mask := 1 shl bitpos; 
s[offset] := s[offset] or mask; 
end; 

I* 

* Return TRUE if e is an element of set s. This is 

* equivalent to (e in s). This version assumes that 

* BITS_PER_BYTE is 8 so it can generate slightly 

* better code. 

*) 

function member(e : integer; var s : bitset) : 
boolean; 

var 

bitpos, offset : integer; 
mask : byte; 

begin 

offset := e shr 3; 
bitpos := e and 7; 
mask := 1 shl bitpos; 


member := (s[offset] and mask) <> 0; 
end; 

{* 

* Intersect sets si and s2, and store the result in 

* si. This is equivalent to si := s2 * s2; 

*1 

procedure intersect(var si, s2 : bitset); 
var 

i : integer; 

begin 

for i := 0 to sizeof(sl) - 1 do 
sl[i] := s 1 [i] and s2[i]; 

end; 

1 * 

* Display a set as a series of bytes (in decimal). 
*) 

procedure display(var s : bitset); 
var 

i : integer; 

begin 

for i := 0 to sizeof(s) - 1 do 
write(s[i]:2, ' '); 

writeln; 

end; 

var 

si, s2 : bitset; 
i : integer; 

begin 

empty(sl); 

write('sl = '); display(sl); 
incl(sl, 10); 
incl(si, 25); 

write('sl * '); display(sl); 
for i := 0 to BITS_PER_SET do 
if member(i, si) then 

writeln(i, 1 is a member of si'); 

empty(s2); 
incl(s2, 11); 
incl(s2, 25); 

write('s2 * '); display(s2); 
intersect(sl, s2); 
write('sl * '); display(sl); 
end. 

( End of File ) 
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if e in s then 


Figure 3 

var 

si : set of 11 .. 20; 
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into 

if member(e, s) then 

but others translate it into 

offset := e shr 3; 

mask := 1 shl (e and 7); 

if (s[offset] and mask) 0 then 


Turbo Pascal uses the former approach; TopSpeed Modula-2 
uses the latter. 

Non-Zero Lower Bounds 

So far, I've been assuming that all sets have 0 as the lower 
bound of the base type. In reality, the lower bound can be 
any non-negative value. For example, 

var 

si : set of 11 .. 20; 

occupies only 10 bits. The most compact representation for 
this set subtracts the lower bound (11) from each element 
value before computing the byte offset and bit position, as 
shown in Figure 3. Using this scheme, a compiler translates a 
membership test like 

if n in si then 

into 

if member(n - lb, s) then 

where lb is the lower bound of the base type of s. 

Unfortunately, this compact mapping makes operations like 
assignment, intersection, and union much more complicated 
in Pascal. In Pascal, two sets are compatible if their base types 
are subranges of the same type. For example, the sets 

var 

si : set of 11 .. 20; 
s2 : set of 14 .. 23; 

are compatible because their base types are subranges of in¬ 
tegers. This means that an operation like 

si := s2; 

is perfectly legal. Conceptually, the compiler converts s2 to a 
set of integers, and then copies the elements in the range 
11..20 to si. Unfortunately, this can't be done with a simple 
byte-by-byte copy, because the elements in s2 have different 
bit positions in si. For example, the bit for 14 is at bit position 
3 in byte 0 of si and in bit 0 of byte 0 of s2. The compiler 
must shift bits within bytes as it copies the sets. 

Turbo Pascal avoids this bit shifting by mapping each ele¬ 
ment in a set into a bit position that's independent of the 


lower bound of the base type. The bit position for element e 
is always 

bitpos := e mod 8; 

Consequently, the first byte of a set may have unused bits in 
the least significant positions to shift the first element of the 
set into its fixed bit position. The byte offset for element e in 
a set with lower bound lb is 

offset := (e div 8) - (lb div 8); 

It follows that the size in bytes for a set of lb. .hb is 

(hb div 8) - (lb div 8) + 1 


GIL 2. 
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fast graphical displays for data 
acquisition and control. 




Rich set of instruments includes: 

Dial gauges, bar gauges, thermometers, seven-segment 
displays, strip-charts, annunciators, alarms, signal 
conditioning, timing, PID control and more! 

All instruments are fully scalable. Virtual coordinates 
allow programs to run unmodified on over 27 video modes! 
Works with any data acquisition hardware, 
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Listing 3 


const 

BITS PER SET = 256; 

BYTES_PER_$ET = 32; 

type 

bitset = array [0 .. BYTES_PER_SET] of byte; 
procedure empty(var s : bitset); 


function member(e : integer; var s ; bitset) : boolean; 


procedure display(var s ; bitset); 


(* 

* Expand set si into (256-element) bitset $2. length is 

* the length in bytes of si. offset is the byte offset 

* in s2 that corresponds to the first byte of si. 

*1 

procedure expand 

(var si; var s2 : bitset; length, offset : byte); 
var 

i, j ; integer; 
p : ^bitset; 

begi n 

p :* addr(sl); 


empty(s2); 
i := offset; 

for j :■ 0 to length - 1 do 
begin 

s2[i] := p A [j]; 
i := i + 1; 
end; 

end; 

const 

LB - 21; 

HB = 50; 
var 

s : set of LB .. HB; 
b : bitset; 
i : integer; 

begin 

s := [22. 32, 42]; 

expand(s, b, HB div 8 - LB div 8 + 1, LB div 8); 
write('b » '); display(b); 
for i := 0 to BITSPERSET do 
if member(i, b) then 

writeln(i:2, ' is a member of b'); 

end. 

( End of File ) 


Figures 4 and 5 illustrate the storage mappings for sets si and 
s2 (declared above) using these formulas. 

Set operations that combine sets with different base type 
ranges are still very complicated. Each operation must know 
the lower and upper bounds of the base types for both sets. 
Turbo Pascal opts for a simpler approach. Nearly all of Turbo 


STAMP OUT 
LISTING 
ERRORS! 

Windows/DOS Developer's Journal 
magazine code listings are already on 
disk. 

Send us $5. Well send you the code. 
Ask for the code by issue number. 

To order, call or write: 

Windows/DOS Developer's Journal 
1601 W. 23rd. St., Ste. 200 
P.O. Box 3127 
Lawrence, KS 66046-0127 
(913) 841-1631 


Pascal's set operators assume the set operands have 256 ele¬ 
ments (32 bytes) in the range 0 to 255. The compiler inserts 
code that expands smaller sets before applying the actual 
operator. Similarly, the compiler generates additional code to 
extract the appropriate bytes from the result. 

Listing 3 presents a Turbo Pascal function that expands a 
set to 32 bytes. Using a function like expond, Turbo Pascal 
compiles the if statement in 

var 

n : integer; 
s : set of 11..40; 

if n in s then 

as something akin to 

expand(s, temp, 5, 1); 
if member(n, temp) then 

where temp is a 32-byte temporary for holding the expanded 
256-element set. 

By the way, Modula-2 simply avoids all these complications 
by permitting set assignment, union, and intersection only for 
sets of identical (not just compatible) types. 

Set Constants 

What is the type of a set constant expression? For ex¬ 
ample, is the Pascal set [‘o' .. 'z'] a set of 'o'.. 'z or a 
set of chart If it is a set of 'a'., 'z', then it has 26 elements 
and occupies four bytes. An expression like 

c in ['a'..'z'] 

must then expand the set into a 32-byte temporary before 
actually testing for membership. If ['a'..'z‘] is a set of 
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var 


Figure 4 

si : set of 11 .. 20; 
si := [11, 15, 19]; 
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s2 : set of 

s2 :« [15, 19, 23]; 
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char, then it has 256 elements occupying 32 bytes, and no 
temporary is needed. 

In Turbo Pascal, ['a'..'z‘ ] is a 32-byte set of char. 
Similarly, a constant set of integers, such as [1, 3, 5], has 
type set of 0..255. Thus, Turbo Pascal generates larger set 
constants in favor of smaller and faster executable code. 

Modula-2 adopts a different policy. The language predefines 
a standard set type 

TYPE 

BITSET = SET OF [0 .. W-l]; 

where U is the number of bits in a machine word. In Top- 
Speed Modula-2, U is 16. The compiler assumes that any set of 
integer constants, such as [3, 7, 14), is a BITSET. 

To specify a set constant of another type, you must 
precede the set constant with the name of the set type. For 
example, using the definitions in Listing 4, sets such as 

{'a', 'e', -i *, 'o', *u'} 

{'O' .. '9'} 

{SEP, APR, JUN, NOV} 

are all illegal because they don't specify the set type. How¬ 
ever, the following are legal 

lower_case_set{'a', 'e', 'i', 'o', 'u'} 
char_set{'a', 'e', ’i', 'o', 'u'} 
char_set{'O' .. '9'} 
month_set{SEP, APR, JUN, NOV) 

In Modula-2, there's never any question about the size of set 
constants or the type compatibility of set constants and vari¬ 
ables. For example, an assignment like 

s := char_set{'d', 's'}; 


Listing 4 

TYPE 

char_set = SET OF CHAR; 
lower_case_set * SET OF ['a' .. 'z']; 
month = (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, 
SEP, OCT, NOV, DEC); 
month_set = SET OF month; 


{ End of File } 


is legal only if s is a char_set. Both the left- and right-hand 
sides of the assignment must have the same type (and size), 
so a simple byte-by-byte copy is all that's needed to imple¬ 
ment the operation. 

Whether To Use A Set 

With this understanding of the underlying implementation 
of set types, you can form better judgments about whether to 
use a set for a particular application. In general, your overrid¬ 
ing concern should be the correctness and clarity of your 
code. Even the slowest set operations aren't very expensive, 
so if sets provide a straightforward solution to a problem, you 
shouldn't be afraid to use them. □ 


"Serialtest is a lifesaver..." 

INFOWORLD, 29 May 1989 


Serial 

Communication 

Problems? 

Take the guesswork out of communications troubleshooting. 
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70 Reader-Contributed Tricks And Hacks 


Tech Tips 



Edited by 
Leor Zolman 


P/ease send us your best 
tricks and hacks — [hose 
clever pieces of code to 
make things work Che way 
they should! You’ll receive 
at lease $50 for each tip 
that we print 
Send your submissions to-. 
TECH Tips 
Leor Zolman 

1601 W. 23rd. SL, Ste. 200 
P.O. Box 3127 
Lawrence, KS 66046-0127 


Mousing Around With QuickBASIC 


Noel Nyman 
Geoduck Developmental Systems 
PO Box 58587 
Seattle, WA 98138 

I just received my August 1991 TECH Specialist. Congratulations on another excel¬ 
lent issue! 

1 particularly enjoyed Phil Weber's article “Enhancing QuickBASIC's Capabilities with 
CALL INTERRUPT.” Months ago, we wanted to add mouse support to a QuickBASIC 
application. To my surprise, I couldn't find any mouse commands in Microsoft’s 
product (BASIC 7.1 does support a mouse through its optional User Interface toolbox). 

Our solution was to call the mouse interrupt 51 (33H) passing the proper values 
through CPU registers and retrieving the results - an ideal CALL INTERRUPT applica¬ 
tion. Unfortunately, the standard QuickBASIC 4.5 printed documentation doesn't 
document this feature very well. I finally found the information in earlier QB 4.0 
manuals. I'd have saved hours of research if Mr. Weber's article had been available. 

Enclosed is a demonstration of CALL INTERRUPT which executes several mouse 
functions on a text screen (see Listing 1.) 

Accessing I/O Ports Under OS/2 Protected Mode 


Donna Campanella 
508 Natalie Lane 
Norristown, PA 19401 




I would like to submit the following technical tip for accessing I/O ports under 
OS/2 protected mode: 

I recently needed to write bytes directly to the keyboard under OS/2 1.3. These 
bytes were not standard keyboard make/break on scan codes. Under DOS, this can 
be easily done in assembly with 

mov dx,0060h ; Keyboard port 

mov ax,00E9h ; byte to write 
out dx.al 

or in C with the function outp(0x60, 0xE9). 


A long time ago, Leor Zolman wrote and distributed the BDS C Compiler for CP/M 
(what's that?). Following a several-gear hiatus from computer-compulsiveness to learn 
some people skills, he got married, dragged his disbelieving wife to Kansas and joined 
the staff of R&D Publications, Inc. Two gears later his wife has almost forgiven him. 
You can reach him at leor@rdpub.corn or uunet!bdsoft!rdpub! leor. 


























Since OS/2 is designed to deter developers from directly 
addressing physical hardware, there was no explicit documen¬ 
tation for writing bytes directly to the keyboard port I inves¬ 
tigated the OS/2 KBD functions and also tried the technique of 
creating a device monitor for the keyboard, but neither 
seemed to do the trick of just sending bytes directly to the 
keyboard port. I needed something akin to the C run-time 
outp function, but the documentation seems to indicate that 
functions of this type should not be used under OS/2. 

The online help for inp and outp state that these func¬ 
tions are "not normally used" under OS/2, and, in fact, the 
code example uses OS/2 functions to perform the equivalent 
of the inp and outp functions. The Microsoft C Advanced 
Programming Techniques manual states that you cannot use 
the C run-time library functions inp and outp for input and 


output because their use is limited to real-mode programs, 
but that inline assembler code can be used access a port. The 
manual further says that OS/2 programs that must access 
hardware directly can designate a code segment with 
input/output privileges which can then perform a limited set 
of input/output instructions. After following the suggestion of 
using inline assembly and explicitly naming segments with I/O 
privileges, I wrestled with many protection violations, only to 
discover that the C functions inp, inpw, outp, and outpw are 
indeed supported under OS/2. However, if you merely place 
the function calls in the code and compile and link as normal, 
a protection violation will surely result. 

The key to accessing ports directly (without generating 
protection violations) is to give the segment input/output 
privileges to do so. To read from or write to ports under OS/2 


Listing 1 

'Demo of CALL INTERRUPT using mouse functions 

'Get mouse position and button status, exit on right button down 

' Noel Nyman 8/91 

PRINT 


PRINT "To test, move the mouse and press the left button ..." 

DEFINT A-Z 

PRINT " Press the right button to exit." 

*SINCLUDE: 'qb.bi* 


DECLARE SUB Mouse (MouseFunction, Buttons, HorizPos, VertPos) 

ExitDemo - FALSE 


DO 

'declare variables passed to SUB Mouse() 

'get mouse position and button status 

DIM MouseFunction, Buttons, HorizPos, VertPos, MinPos, MaxPos 

MouseFunction ■ GetPos 


CALL Mouse(MouseFunction, Buttons, HorizPos, VertPos) 

'define global Booleans 

LOCATE 8, 1 

TRUE * -1 

PRINT "Horizontal position: HorizPos 

FALSE - NOT TRUE 



LOCATE 9, 1 

'define mouse functions 

PRINT "Vertical position: "; VertPos 

Installed * 0 'check for mouse installed, reset 


Show = 1 'show cursor 

IF Buttons AND 1 THEN 

Hide * 2 'hide cursor 

LOCATE 11, 1 

GetPos « 3 'get mouse position and button status 

PRINT "Left Button down" 

SetPos - 4 'set mouse cursor position 

ELSE 


LOCATE 11, 1 'left button not down 

GetPress * 5 'get button press info 

PRINT SPACES(16) 

GetRelease * 6 'get buton release info 

END IF 

SetHorizRange ■ 7 'set min/max horiz position 


SetVertRange - 8 'set min/max vert position 

IF Buttons AND 2 THEN 

SetGraphics * 9 'set graphics cursor block 

LOCATE 12, 1 


PRINT "Right Button down" 

SetText * 10 'set text cursor 

ExitDemo = TRUE 

ReadMotion * 11 'read motion counters 

END IF 

SetMask * 12 'set user sub input mask 


PenOn * 13 'light pen emulation on 

LOOP WHILE NOT ExitDemo 

PenOff ■ 14 'light pen emulation off 



LOCATE 14, 1 

Mickey * 15 'set mickey/pixel ratio 

PRINT "Demo ended by right button press." 

CondOff * 16 'conditional off 


DoubleSpeed ■ 19 'set double speed threshold 

'turn mouse cursor off 


MouseFunction - Hide 

'— main code starts here — 

CALL Mouse(MouseFunction, 0, 0, 0) 

CLS 


PRINT "Demo of CALL INTERRUPT using mouse functions." 

ELSE 

PRINT 

PRINT "Mouse not installed." 


END IF 

'check for a mouse and mouse driver 


MouseFunction * Installed 

END 

CALL Mouse(MouseFunction, 0, 0, 0) 


IF MouseFunction THEN 

'Call mouse driver through interrupt H33. 

PRINT "Mouse installed." 



SUB Mouse (MouseFunction, Buttons, HorizPos, VertPos) 

'show the text cursor 


MouseFunction * Show 

DIM Regs AS RegType 

CALL Mouse(MouseFunction, 0, 0, 0) 

Regs.ax * MouseFunction 


Regs.bx ■ Buttons 

'limit mouse to the lower left of the screen 

Regs.cx - HorizPos 

MouseFunction - SetHorizRange 


MinPos ■ 0 

Regs.dx - VertPos 

MaxPos * 240 

CALL Interrupt(&H33, Regs, Regs) 

CALL Mouse(MouseFunction, 0, MinPos, MaxPos) 



'return variables from mouse driver 


MouseFunction ■ Regs.ax 

MouseFunction - SetVertRange 

Buttons * Regs.bx 

MinPos ■ 96 

HorizPos - Regs.cx 

MaxPos - 176 

VertPos • Regs.dx 

CALL Mouse(MouseFunction, 0, MinPos, MaxPos) 



END SUB 


/* End of File */ 


February 1992 


Windows/DOS Developer’s Journal — Page 71 




protected mode, you must have a .DEF module-definition file 
that gives IOPL (input/output) privilege to the _IOSEG segment. 
(You can check the .MAP file for the associated segment name 
or compile with the /NT switch to manually name the seg¬ 
ment.) Since IOPL cannot be done from a regular code seg¬ 
ment, the run-time library has declared a separate code seg¬ 
ment called IOSEG. To use these types of functions (that 
directly address hardware ports) in protected mode run-time 
libraries, the .DEF file must contain the line 

SEGMENTS IOSEG CLASS ‘IOSEG CODE' IOPL 


Listing 2 

// TESTKBD.C Program to write a byte directly to the 
// keyboard at port Hex 60. 

// Output functions are outp(<port>, <databyte>) 

// or outpw(<port>, <dataword>) 

// <port> can be any unsigned integer in the range 0-65,535 
// for outp, <databyte> can be any integer in the range 0-255 
// for outpw, <dataword> can be any value in the range 0-65,535 

linclude <conio.h> 

int main() 

{ 

outp(0x60, 0xE9); 
return 0; 

} 

/* End of File */ 
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Windows/DOS Developer’s Journal 

1601 W. 23rd St., Ste. 200 
P.O. Box 3127 
Lawrence, KS 66046-0127 
(913) 841-1631 


The sample listings illustrate all that's needed to write a byte 
directly to the keyboard. Listing 2 is the sample C program, 
TESTKBD.C. Listing 3 shows an OS/2 command file to compile 
and link TESTKBD.C. Listing 4 is the module definition file, 
TESTKBD.DEF, and Listing 5 is the MAP file generated by the 
compilation (showing _I0SEG and I0SEG_C0DE). 

Note that I0PL=YES must be specified in the CONFIG.SYS 
for programs with I/O privileges to load. 

Since the documentation is vague concerning this topic, I 
hope this tip helps others trying to read or write directly to 
ports under OS/2. For further questions, I can be reached on 
CompuServe as 72010,2305. □ 


Listing 3 

rem Compile and Link TESTKBD 
cl -c testkbd.c 

link testkbd,/align:16,testkbd,.testkbd 


Listing 4 

; Module Definition file for TESTKBD 

NAME TESTKBD WIND0WC0MPAT 

DESCRIPTION 'Test writing to Keyboard at port Hex 60' 



Listing 5 


testkbd 



Start Length 

Name 

Class 

0001:0000 00002H 

IOSEG 

IOSEG CODE 

0002:0000 006B8H 

TEXT 

CODE 

0003:0000 00002H 

EMULATOR TEXT 

CODE 

0004:0000 00000H 

C ETEXT 

ENDCODE 

0004:0000 00000H 

EMULATOR DATA 

FAR DATA 

0004:0000 00042H 

NULL 

BEGOATA 

0004:0042 0008AH 

DATA 

DATA 

0004:00CC 0000EH 

CDATA 

DATA 

0004:00DA 00000H 

XIFB 

DATA 

0004.-O0DA 00000H 

XIF 

DATA 

0O04:O0DA OOOOOH 

XIFE 

DATA 

0004.-00DA OOOOOH 

XIB 

DATA 

0004:00DA OOOOOH 

XI 

DATA 

0004:00DA OOOOOH 

XIE 

DATA 

0004:00DA OOOOOH 

XPB 

DATA 

0004:00DA OOOOOH 

XP 

DATA 

0004:00DA OOOOOH 

XPE 

DATA 

0004:00DA OOOOOH 

XCB 

DATA 

0004:00DA OOOOOH 

xc 

DATA 

0004:00DA OOOOOH 

XCE 

DATA 

0004:00DA OOOOOH 

XCFB 

DATA 

0004:00DA OOOOOH 

XCF 

DATA 

0004:00DA OOOOOH 

XCFE 

DATA 

0004:00DA OOOOOH 

CONST 

CONST 

0004:00DA 00008H 

HDR 

MSG 

0004:00E2 00102H 

MSG 

MSG 

0004:01E4 00002H 

PAD 

MSG 

0004:01E6 00001H 

EPAD 

MSG 

0004:01E8 OOOOOH 

BSS 

BSS 

0004:01E8 OOOOOH 

XOB 

BSS 

0004:01E8 OOOOOH 

xo 

BSS 

0004:01E8 OOOOOH 

XOE 

BSS 

0004:01F0 00A00H 

STACK 

STACK 

Origin Group 



0004:0 DGROUP 



Program entry point 

at 0002:0026 
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New Products 

Industry-Related News & Announcements 


Outrider Augments Visual Basic Interface 

Outrider Systems, Inc., has released two new tools for 
Visual Basic Developers: ButtonTool and EditTool. ButtonTool 
allows Visual Basic programmers to place graphics symbols 
and captions on buttons. The program comes with 18 
predefined symbols. In addition, programmers can specify 
bitmaps, icons, or metafiles as a button’s foreground. Button- 
Tool includes the ability to create shadows and three-dimen¬ 
sional effects. Developers can also use ButtonTool to create 
enhanced picture fields or labels with shadows and three- 
dimensional effects. 

EditTool provides input field masking for text entry. For 
example, you can use EditTool to require each character the 


user types to be alphabetic or numeric You can also specify 
input field validation for dates, currency, Social Security num¬ 
bers, phone numbers, and others. Like ButtonTool, EditTool 
allows you to control shadows, borders, and colors. EditTool 
also provides a spin control for cycling through a specific 
range of values. 

Both tools load into the Visual Basic tool palette and 
neither requires runtime royalties. The tools cost $49.95 
each; the company is offering an introductory price of $89.95 
for both. For more information, contact Outrider Systems, 
Inc., 3701 Kirby Drive, Suite 1196, Houston, TX 77098, 

(713) 521-0486; FAX (713) 523-0386. 


MDBS Enhances Object/1 Windows Support 


Micro Data Base Systems, Inc., has released Object/1 v2.1 
for Windows 3.0 and Windows 3.1. Object/1 is an object- 
oriented graphical development environment for Windows 
and PM. In addition to its object-oriented programming lan¬ 
guage, Object/1 includes Forms Painter, a user interface 
management system, and TBL, a relational database system. 
Object/1 can interface with MDBS IV, SQL Server, Sybase, and 
IBM Database Manager, using the object classes within the 
Object/1 Professional Packs. 

This version of Object/1 now allows Forms Painter to use 
Windows bitmaps and icons as background or as Object/1 
controls. You can also size and stretch bitmap images. The 
update includes source code for bitmap handling to facilitate 
image processing tasks. This version also supports vector 


fonts and Windows 3.1 Truetype scalable fonts. Both the Ob¬ 
ject/1 kernel and the Forms Painter contain performance en¬ 
hancements and the update includes new online 
demonstration application and help facilities, providing 
coding assistance to developers implementing windows, 

DDE, and other customized GUI functionality. 

An Object/1 Tutorial is included with each update to aid 
developers of Object/1 Windows applications. The Object/1 
development system costs $995. Royalty-free application dis¬ 
tribution costs an additional $995. For more information, con¬ 
tact Micro Data Base Systems, Inc., Two Executive Drive, 
P.O. Box 6089, Lafayette, IN 47903-6089, (800) 344-5832; 
FAX (317) 448-6428. 


Library Provides Windows API For DOS Programs 


Interactive Engineering Corporation has released WIN- 
DOWS.TXT, a DOS, text-mode version of the Windows API. 
WINDOWS.TXT allows developers to use Windows source 
code, development tools, and references to create native 
DOS applications. Once you write a program for Windows, 
you can use WINDOWS.TXT to quickly port it to DOS. WIN¬ 
DOWS.TXT allows DOS programmers to take advantage of 
Windows features such as overlapped windows, menus, 
dialog boxes, hypertext help, resources, event-driven ar¬ 
chitecture, handle-based memory management, GDI paint¬ 
ing, clipboard exchange, mouse support, and serial 
communications. 


The WINDOWS.TXT package includes licensed Microsoft 
Windows SDK components, C/C++ libraries for Microsoft, Bor¬ 
land, and Zortech compilers, Microsoft Windows Guide to 
Programming, Microsoft Windows Programmers Reference, 
WINDOWS.TXT User’s Guide. The package also includes a 
resource compiler, dialog editor, compatibility checker, and a 
utility for dual-monitor debugging. 

WINDOWS.TXT costs $395, or $695 with library source. 

The package is royalty-free. For more information, contact In¬ 
teractive Engineering Corporation, P.O. Box 7022, Boulder, 
CO 80306-7022, (303) 440-7674; FAX (303) 444-7206. 
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EmmaSoft Updates SUPER-MAINT 

EmmaSoft has released version 2.11 of its make utility, 
Programmer's SUPER-MAINT. SUPER-MAINT is a program main¬ 
tenance utility that helps automate the task of compiling 
and linking software. SUPER-MAINT remembers past settings 
including the name of the most recent make file and can 
even write make files for you, using a simple point-and- 
shoot interface. It can write correct compilation commands 
for Microsoft, Borland, Mix, and Aztec compilers, and for Clip¬ 
per. SUPER-MAINT includes a local setup option that allows 
you to work on several projects with different setups at the 
same time. 


This version can now swap all but about 2Kb of itself to 
either EMS memory or disk, leaving more memory for com¬ 
pilers or other tools used during program builds. This version 
also fixes a bug in the help facility (the previous version dis¬ 
played some of the chapters in the on-screen manual incor¬ 
rectly when called with a mouse). Another new feature is 
the ability to call .COM and batch programs in addition to 
.EXE and internal DOS commands. 

SUPER-MAINT v2.11 costs $55 is is available directly from 
EmmaSoft For more information, contact EmmaSoft, P.O. 
Box 238, Lansing, NY 14882-0238, (607) 533-4685 (voice 
or FAX); BBS (607) 533-7072; CIS 71460,2644. 


C Tool Analyzes Execution Paths 


Softran Corporation has released C-Verify, a test coverage 
analysis tool for C programs. C-Verify reads your source code 
modules and produces both an index of all possible execu¬ 
tion branches and a new copy of the source containing func¬ 
tion calls to log branches actually taken. After recompiling, 
you can run your test suite and each test will log the execu¬ 
tion branches taken to an output file for analysis. After you 


finish running tests, C-Verify can identify which sections of 
your code were never exercised by the test suite. 

C-Verify is available for DOS and UNIX. The DOS version 
costs $395 and the UNIX version costs $795. For more infor¬ 
mation, contact Softran Corporation, One Naperville Plaza, 
Naperville, IL 60563, (800) 462-3932; (708) 505 3456; FAX 
(708) 505-3457. 


MDBS Creates Visual Basic And C++ interfaces 


Micro Data Base Systems, Inc. has created three new 
Windows-based language interfaces for MDBS IV and M/4 for 
Windows. MDBS IV is an online transaction-processing DBMS 
available for DOS, OS/2, most LANs, UNIX, MPE/XL, and VAX 
VMS. M/4 for Windows is a standalone Windows DBMS. Now 
users of Visual Basic, Zortech C++, and Borland C++ can write 
Windows applications that access these two database sys¬ 
tems. 

The Visual Basic interface for MDBS IV comes with a Win¬ 
dows DLL containing the MDBS IV API, a Visual Basic global 
module, and documentation detailing the use of MDBS IV 
with Visual Basic. The package also includes a program that 
demonstrates MDBS IV database calls. The C++ interfaces use 


Borland's and Zortech's calling mechanisms and include 
sample programs, documentation, and a Windows DLL con¬ 
taining the MDBS IV API. 

The M/4 for Windows development system costs $995 
and comes with the Microsoft C language interface. Each ad¬ 
ditional language interface costs $195. MDBS IV development 
systems start at $3,900, depending on the operating system 
and hardware platform and comes with your choice of lan¬ 
guage interface. Each additional language interface for MDBS 
IV costs $1,175. For more information, contact Micro Data 
Base Systems, Inc., Two Executive Drive, P.O. Box 6089, 
Lafayette, IN 47903-6089, (800) 344-5832; FAX (317) 448- 
6428. 


Crescent Releases P.D.Q. V3.0 

P.D.Q. is a replacement library for creating smaller and 
faster programs using Microsoft compiled BASIC. You compile 
your BASIC source file as usual, then link with the PDQ.LIB in¬ 
stead of the normal BCOM library that comes with the com¬ 
piler. The resulting program is typically smaller and faster. 
The minimum resulting .EXE file size is 370 bytes and useful 
programs can be written in less than 2Kb. P.D.Q. also lets 
BASIC programmers create TSRs and interrupt handlers 
without resorting to assembly language. 

Version 3.0 includes support for floating-point math that 
automatically uses an 8087 if it is present. This version also 
supports all network file operations, EGA and VGA graphics 
primitives, TSRs that swap to disk or EMS to take as little 


memory as possible when idle, bit manipulation, and safe 
DOS and BIOS access even within a TSR interrupt handler. 

The documentation has been rewritten and expanded to 
500 pages. The documentation now describes how to use 
P.D.Q. as a toolbox with assembly language. It demonstrates 
how to use the floating-point emulator and TSR services in a 
non-BASIC program. 

P.D.Q. v3.0 costs $149 and includes complete assembly 
language source code for the library and examples. For more 
information, contact Crescent Software, Inc., 32 Seventy 
Acres, West Redding, CT 06896, (203) 438-5300; FAX (203) 
431-4626; CIS 72657,3070. 


Black Ice Creates GIF SDK 


Black Ice Software, Inc., is shipping a Graphics Inter¬ 
change Format (GIF) SDK for Windows. The GIF SDK is a set of 
software tools that allow developers to write programs that 
read and write GIF image files. The GIF graphics format was 
designed several years ago to allow the exchange of high- 
resolution color images between different hardware plat¬ 
forms. Thousands of GIF images are available on networks 
and bulletin boards. The GIF SDK makes it easy for your ap¬ 
plication to support this popular graphics file format 


The routines in the GIF SDK allow you to load GIF files 
into Device Independent Bitmaps (DIBs) or save a bitmap in 
the GIF format with a single function call. The GIF SDK is in 
the form of a DLL, so it is accessible from a wide variety of 
Windows languages and programming environments. The 
GIF SDK costs $149 and includes complete documentation. 
For more information, contact Black Ice Software, Inc., 
Crane Road, Somers, NY 10589, (914) 277-7006; FAX (914) 
276-8418. 
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SST Brings Data Acquisition To Visual Basic 


Scientific Software Tools, Inc (SST) has announced 
DriverLINX for Visual Basic, a new series of real-time data-ac- 
quisition engines for third-party, high-speed analog and digi¬ 
tal I/O boards. DriverLINX allows scientists and engineers to 
access popular data-acquisition hardware from their Visual 
Basic programs. DriverLINX is a Visual Basic custom control. 
Users can choose from more than 100 functions for creating 
foreground and background tasks to perform analog I/O, digi¬ 
tal I/O, time and frequency measurement, event counting, 
pulse output, and period measurements. 

DriverLINX implements an abstract, task-oriented model 
of data-acquisition hardware, freeing the user from low-level 
hardware details. The product provides memory and data 
buffer management, pre-, mid-point, and post-triggering 


protocols, built-in functions to display dialog boxes for con¬ 
figuration management and data-acquisition setup task 
entry, a context-sensitive online help facility, and error¬ 
checking and reporting capabilities. It can manage up to six 
data-acquisition boards and ten concurrent tasks. 

DriverLINX for Visual Basic costs $400 and supports the 
Keithley Metrabyte DAS-16 models, Advantech PCL-718/818 
models, Computer Boards CIO-AD-16, Soltec SC-7180, In¬ 
dustrial Computer Source AIO-16, Scientific Solutions Lab- 
master DMA, Data Translation 2801 Series, and ADAC's 
Optimum Conversion Series. For more information, contact 
Scientific Software Tools, Inc., Penn State Technology 
Development Center, 30 East Sw edesford Road, Malvern, 
PA 19355, (215) 889-1354; FAX (215) 889-1630. 


ProtoView Updates Screen Painter 

ProtoView Development Corporation has released ver¬ 
sion 3.2 of ProtoView, a user interface and code generator 
tool for Windows C programmers. This version contains an 
enhanced ViewPaint screen painter, featuring customizable 
toolboxes and palettes. This allows a user to choose which 
drawing tools are available at any given time. By loading a 
new workbench, the user can quickly change the set of con¬ 
trol objects and tools available for painting. Groups can dis¬ 
tribute and use the same workbench to encourage uniform 
screen design. 

This version also contains more powerful data formatting 
and validation capabilities, data entry control objects for six 
international date formats, and twenty-six international cur¬ 


rencies. The new version includes enhanced support for DDE 
conversations between ProtoView dialogs and other applica¬ 
tions. The ProtoView screen painter can now place bitmaps 
and icons within pushbuttons. Data entry Fields now support 
multiple range checking. The new version also contains en¬ 
hanced code generation for Borland C++ and Zortech C++. 

ProtoView v3.2 costs $695. Upgrading from ProtoView 
v3.1 or v3.1a costs $100 plus $6 shipping; upgrading from ear¬ 
lier versions costs $200 plus $6 shipping. For more informa¬ 
tion, contact ProtoView Development Corporation, 353 
Georges Road, Dayton, NJ 08810, (908) 329-8588; FAX 
(908) 329-8624. 


GEOGRAF Adds Graphics Tools To Borland C++ 


GEOCOMP Corporation has released GEOGRAF Level One 
for Borland Turbo C++, which allows Borland C++ program¬ 
mers to add customized graphics to their programs. 

GEOGRAF Level One is a graphics library that simplifies creat¬ 
ing custom graphs and charts. GEOGRAPH Level One supports 
13 fonts and four line types. You can import plots from the 
product into any program that accepts HPGL files, such as 
WordPerfect 5.1 and Microsoft Word. 

GEOGRAF Level One supports over 250 different output 
devices, saving programmers from writing complex drivers 
for each device they wish to support. The included device 
drivers support most graphics cards, dot matrix printers, in¬ 


kjet printers, laser printers, and pen plotters. You can change 
device drivers at any time without changing the software. 

GEOGRAF Level One for Borland Turbo C++ costs $149 and 
includes documentation and a 30-day money-back guaran¬ 
tee. GEOGRAF Level One is also available for Microsoft C, 
Microsoft QuickC, BASIC PDS 7, Borland Turbo C and Turbo 
C++. Other GEOGRAF libraries are available for popular C, 
FORTRAN, and BASIC compilers. For more information, con¬ 
tact GEOCOMP Corporation, 66 Commonwealth Avenue, 
Concord, MA 01742, (800) 822-2669; FAX (508) 369-4392. 


PANEL Plus II Supports Windows 

PANEL Plus II is a screen manager for C and C++ 
programs. Roundhill Computer Systems Limited has released 
PANEL Plus II V2.20, which adds support for Microsoft Win¬ 
dows. Programs written with PANEL Plus II can run with no 
source code changes under DOS, OS/2, UNIX, VMS, and now 
Windows. PANEL Plus II applications running under Windows 
can access all PANEL Plus II features, including multiple-line 
scrollable fields, menus, popups, scrolling regions, CUA com¬ 
patibility, and custom validation by character or field. 

Existing PANEL Plus II users can convert programs to Win¬ 
dows applications without having to re-think, re-design, and 
re-code them to conform to Windows. Once applications are 


running under Windows, you can gradually enhance them, if 
necessary, by adding direct Windows API calls. The package 
includes both text-mode and Windows versions of an inter¬ 
active screen design editor and a C code generator for 
screen layouts. 

PANEL Plus II v2.20 costs $495 and includes full library 
source. Libraries and DLLs are available for all leading C and 
C++ compilers that allow Windows development For more 
information, contact Roundhill Computer Systems, at (708) 
690-3737; FAX (708) 665-9841. 


February 1992 


Windows/DOS Developer’s Journal - Page 75 








Readers' Forum 


We ask that letters with code listings be 
submitted in an ASCII text file on an MS- 
DOS formatted disk. Providing us an 
electronic copy of the code will prevent 
typographical errors that might result 
from optical scanning or re-keyboarding. 


Dear Ron: 

In response to your response to a 
letter in the November 1991 issue 
regarding TSRs, let me offer the follow¬ 
ing additional comments. If a TSR is 
spawned from a shell that allocates the 
environment itself, the TSR could free 
memory that should not be freed. 
Under some instances, there will be no 
environment. You must check for this 
before attempting to free the environ¬ 
ment. If there is no environment, the 
PSP will contain zero at offset 2ch. The 
following procedure in assembly 
demonstrates the concept: 

ReleaseEnv proc near 
push ax 
push bx 
push es 

mo. ah, 62. ; get PSP address 
in. 21h 

mo. es, b. ; es <- PSP 
xo. ax, a. ; clear ax 
xchg ax, es:2CH 

o. ax, ax ; check for environment 
j. NoEn. ; if 0, no environment 
mo. es, ax ; es has environment 
mo. ah, 49h; free the block 
in. 21h 
NoEnv: 
pop es 
pop bx 
pop ax 
ret 

ReleaseEnv endp 
Keep up the good work! 

Mark T. Edmead 
MTE Industries 
P.O. Box 2477 
Del Mar, CA 92014 

Thanks for the tip. —rib 


Dear Mr. Burk, 

Concerning the TSR issue in the 
"Readers' Forum” in the November 1991 


issue, it is perfectly permissible to 
release the environment from a TSR if 
you so choose. Each program (whether 
it will ultimately remain resident or not) 
is given a copy of the parent's environ¬ 
ment. A DOS memory control block is 
created for this environment and the 
owner of this block is the PSP of the 
subject program. 

As far as writing over bytes marked 
“reserved” in the PSP, yes, that is 
dangerous. However, there are some 
bytes marked “unused” in the PSP. I 
have found that even these should not 
be touched. Offset 56 (decimal) for in¬ 
stance is the beginning of a 20-byte 
area marked “unused.” However, in DOS 
5.0, this word is used for the DOS ver¬ 
sion number to be returned to this pro¬ 
gram if the Get DOS Version Number 
function is called by the program. Evi¬ 
dently, this is part of the SETVER sys¬ 
tem. 

I was using some of the areas 
marked “unused” in the PSP with my 
commercial TSR for runtime variables in 
order to reduce the program’s memory 
requirements as much as possible. For¬ 
tunately, my program was able to be 
fixed by merely checking the DOS ver¬ 
sion number at the very beginning of 
my program, before overwriting this 
area. In short, the only area in the PSP 
that can be reliably scribbled on is the 
128-byte area starting at offset 128 
(decimal). This holds the command line 
to your program. 

Chris Wilson 
Wilsoft, Inc. 

109 NW 22 Street 
Ft. Lauderdale, FL 3331 1 

Thanks for the undocumented infor¬ 
mation. -rib. 


To The Editor: 

I am compelled to respond to the 
editorial that appeared in the October 
issue of TECH Specialist. It appears that 
Ron Burk bases his negative opinion of 
Hungarian notation on Charles Simonyi's 
writings, rather than on any actual ex¬ 


perience using the system. I have three 
years of actual experience, and that ex¬ 
perience has been very positive. 

Programmers have long encoded the 
types of variables in their names, but it 
has been done in an ad-hoc manner. 
How many times have you seen the 
whole word or an abbreviation of 
count, flag, or pointer in a variable 
name? I see a lot of this in non-Hun¬ 
garian code. Hungarian notation simply 
brings consistency to this existing prac¬ 
tice. 

I think it is very important to view 
Hungarian notation as a concept, and to 
feel free to implement that concept as 
it is most appropriate to your own 
projects. You don't have to use the 
notation exactly as Charles Simonyi 
does. In my own work I use a limited 
set of prefixes, certainly not one for 
every type in my program. When I use 
a prefix it is always part of a longer 
descriptive name; I would never name a 
variable with just the prefix itself. 

There are a few areas where I have 
found Hungarian notation especially 
useful. When writing low-level code, 
you must often deal with bytes, words, 
and near and far pointers. I find it a 
tremendous help to encode these types 
into variable names. It isn't that the 
compiler wouldn't catch type mis¬ 
matches, it is that I simply don’t write 
incorrect code in the first place when 
the types are clear. 

I'd like to conclude by echoing the 
final point in Ron Burk's editorial: The 
purpose of a variable, not its data type, 
is the most important attribute. I agree 
with this fully, which is why 95 percent 
of the characters in my variable names 
are used to describe what the variable 
does. I also believe that data type often 
has a direct effect on the purpose and 
usage of a variable, and that it is worth 
two or three characters to encode that 
information as well. 

John McNamee 
2500 Broadway, Suite 200 
Santa Monica, CA 90404 

Your point of view is a lot more 
reasonable than the article Byte ran - 
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maybe you should offer to write one 
for them! A type encoding followed by 
a mnemonic name is not so bad. Un¬ 
fortunately, there’s no getting around 
the fact that this does not follow the 
procedure defined by the inventor of 
the Hungarian naming convention, 
since he clearly states his opposition 
to mnemonic names. I suggest we 
refer to your naming convention as 
“Modified-Hungarian," or “Mnemonic- 
Hungarian," or “Maintainable-Hun- 
garian.” I suspect most programmers 
who believe they are using Hungarian 
notation are doing just as you suggest. 
Only folks who never have to maintain 
code can live with short, random char¬ 
acter strings for names. —rib 


Dear Sirs, 

In trying to get the 42-byte 
HELLO.COM mentioned in "Modifying 
CONFIG.SYS During Startup" in your Sep¬ 
tember 1991 issue, I found that unless I 
split up TINY LIB. C into its component 
functions and TLIBe d individual OfiJects 
into the LIB, TLINK would link in all of 
TINYLIB, thus giving me a big 320-byte 
file. (Actually, 318 bytes since I changed 
a MOV AX,0 into a SUB AX,AX or 
maybe an XOR.) I was using Borland C++ 
(as opposed to Turbo C) if that makes 
any difference. I couldn't find a method 
of only linking in what was necessary 
and keeping the source code together 
in the manuals or any third-party 
books. (I suppose a bunch of Hfs et al. 
might have made many objects out of 
one source file.) I found this article in¬ 


teresting because I wanted to read the 
command-line arguments and distin¬ 
guish between tab-separators and 2- 
space separators between arguments 
and the Turbo c family normally makes 
this difficult and now I can do this 
without quite using pure assembly lan¬ 
guage. 

Did you know that MS-DOS still has a 
convert-from CP/M programming inter¬ 
face? For example: 

MOV CL,2 
MOV DL.'A' 

CALL 5 

still works in the Tiny model. Thank you 
very much. 

Joel M. Rubin 
P.0. Box 423131 
San Francisco, CA 94142-3131 
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TUB “ is FASTEST! 
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RCS’“ 4.2 

PVCS” 

TUB™ 3.0 TUB’" 5.0 


Times are to update a 45K library on a PC/XT. PVCS and TUB 3.0 are 
from Sept 87 PC Tech Journal. MKS RCS 4.2 and TUB 5.0 are newer. 

TUB™ is BEST! 

“Do not be fooled by the fact that this is the 
least expensive of the five packages reviewed 
here - TUB has features and power to spare ” 
John Rex, Computer Language 
“TUB is a great system" J. Vallino, PC Tech J 

. Full-Featured Version Control for Software 
Professionals. Check-in/out locking. Branching. 
Keywords. Wildcard and list-of-file support. Can 
merge parallel changes and undo intermediate 
revisions. Network and WORM support. Main¬ 
frame compatible deltas for Pansophic, ADR, IBM, 
etc.. Integrates with Opus™ MAKE & Slick’" MAKE. 

MS-DOS $139, OS/2 $195 + shipping visa/MC 
5 station LAN license $419 (OS/2 $595), call for other sizes 

BURTON SYSTEMS SOFTWARE 

PO Box 4156, Cary, NC 27519 (919)233-8128 
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SYSTEMS CORPORATION 

X-Port Parallel Adapter 

Expand mass store capabilities 

Attach CD-ROM and SCSI based 
peripherals to a single parallel port 

Comes with drivers for DOS, MSDEX 

Low power, compact size 

For notebooks, laptops, desktops 

$225 + shipping & handling 

PO, Cheque, VISA 

300 March Rd., 4th Floor, 

Kanata, Ontario, Canada, K2K 2E2 
(613) 591-3084 (613) 591-1806 (fax) 
Dealer & OEM enquiries welcomed 
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Wrltebar Barcode Products 

Wilsoft carries a complete line of bar 
code software and hardware for your 
every need. All major bar code types 
supported. Call the most experienced 
company in the bar code field today. 
DOS and Xenix/Unix support. Por¬ 
table readers too! VISA/MC/AMEX 

109 NW 22 Street 
Ft. Lauderdale, FL 33311-3834 
(305) 779-2720 
(305) 763-3096 Fax 
(800) 765-4114 Sales 
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EGAD 

Screen Print Package 

• Supports VGA, EGA, CGA, 
MGA displays up to 800x600 

• Select printout colors/gray 
tones; print any rectangular 
region; enlarge graphics 1-4 
times; many other features 

• Works with most printers 

• TSR (Shift-PrtSc) or call from 
your program. TSR is 9-15K. 

• Licensing available. 

$35.00 postpaid. Free catalog. 


LS Software 8139 E. Mawson, 
Mesa, AZ 85207 (602) 380-9175 
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Opt-Tech Sort/Merge 


Extremely fast Sort / Merge / 
Select utility. Run as an MS- 
DOS command or CALL as a 
subroutine. 

Supports most languages and 
filetypes including Btrieve and 
dBase. Unlimited filesizes, mul¬ 
tiple keys and much more! 

MS-DOS $149. 

OS/2, UNIX $249. 


Opt-Tech Data Processing 

P. O. Box 678 
Zephyr Cove. NV 89448 

(702) 588-3737 
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I certainly used to know that, since 
the first PC I used was a Zenith Z-100 
that also ran CPM. Unfortunately, new 
knowledge seems to be squeezing old 
knowledge out of my brain, and CP/M 
was an early fatality. As for your prob¬ 
lem with tinylib.c, that is totally my 
fault. The author submitted them 
broken apart and I combined them in 
order to save space in the magazine 
listings. I forgot to consider that this 
would create a single, indivisible ob¬ 
ject module. Thanks for pointing out 
my error. I gave the code you sub¬ 
mitted to Leor for consideration as a 
TECH Tip. -rib 


Dear Editor: 

You’re right: the name "TECH 
Specialist” didn't mean a thing. “DOS" is 
okay, but l wonder about "WINDOWS.” I 


get the distinct feeling that the term 
“Windows” was invented to perk up 
software sales-, and that when they 
begin sagging again maybe that'll be 
deserted for “Doors” or something 
equally tacky. We shall see. 

The reason for this letter: Someone 
has said that there are lots of 
magazines for hackers. To that person I 
say, “Name two.” 

I regularly subscribe to your 
magazine, The C Users Journal, Computer 
Language, Dr. Dobb's Journal, and PC 
Techniques. It appears to me that all 
these are directed at the professional 
programmer, although I find it hard to 
believe that all the readership can be in 
that category. While I enjoy them all, 
and even learn some things, most of 
the material is for experts in one lan¬ 
guage or other - not for me and others 


like me. (I consider myself a hobby 
programmer - eager to learn something 
about all languages and all aspects of 
programming; but I don't do it for a 
living.) 

Here's my point: From time to time I 
and others come up with gems that a 
professional programmer wouldn't be 
caught dead with, but that are useful 
and perhaps even innovative. If they 
use DOS, batch or BASIC, forget about 
having them appear in any periodical 
presently in publication. 

For example cast your eyeballs over 
the enclosed items. While useful and in¬ 
novative, I'll bet your magazine won't 
touch them; well, you're not alone. 
There appears to be no outlet for this 
kind of stuff since PC Resource stopped 
publishing. 
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f Windows Developers:^ 

Put an End to Memory Problems! 


OptiMem™ 

for Windows 


Optimal memory manage¬ 
ment DLL for Windows 3.x. 


□ Fixes selector consumption, overhead, granu¬ 
larity, fragmentation. Supports heaps > 64K. 

□ Dramatically improves performance. 

□ ANSI C malloc, C++ new, dozens more APIs. 

□ Detects memory bugs including double-freeing, 
memory overwrites, wild pointers, and more! 

□ Programmatic heap walking and error handling. 

□ Ideal for dynamic data structures, e.g. lists. 


n®’ Only $249 + $5 s/h. Includes full source code! 
Free, unlimited technical support. No royalties. 

Unconditional 60-Day Money-Back Guarantee! 

Call now to order or to request free brochure! 


Applegate Software 

/o qcq QC4o 4317264th Avg NE 

(206 ) 868-8512 Redmond WA gg0S3 ^ 
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CopyControl 
COPY PROTECTION 


Control your profits with the copy protection designed 
with strength, user-transparency and compatibility. 

• Beats ALL the bit-copiers & Dis-assemblers 

• No hardware plugs or special disks required 

• Encrypts your program & adds anti-debug code 

• Allows you to produce full function demos 
•Compatible with LAN, backups & disk utilities 

• Supports all Floppy & Hard disk formats 

• Allows you to change parameters remotely. 


Control when, where, and how your software is ran. 
Compatible with all IBM/DOS Computers. 

$595 Unlimited Version, 30 day Money back guarantee 
Also available by Meter Count CSE| 
Free Demo & Into • COD • PO Iw 1 ! 


Tlicrocosm Inc. 


Drawer 0, Wellington, MO 64097 


(800) 237-8400 ext. 212 
(816) 934-8384 / Fax (816) 934-2617 
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INTEL® 80486 
MACRO DISASSEMBLER 

MD86 (Masterful Disassembler) is the 
most comprehensive macro disassembler 
on the market. Interactive by design not 
after thought. Features include: 


► User defined macros with arguments 

► Auto code/data separation 

► Auto commenting and label naming 

► Command menus and help screens 

► Customizable disassembly options 

► Comprehensive, indexed, manuals 

► Fully supports 8086/87 thru 80486/87 

► COM/EXE/SYS/memory/othe^ 

► Cross reference and more! 

Still only $67.50 +tax ($1.50 s/h) 

C.C.SOFTWARE 
1907 ALVARADO AVE. 

WALNUT CREEK, CA 94596 
(510)939-8153 






• 1, 2, DR 4 PORT RS-232 BOARDS 

• RS-232 AND RS-422 VERSIONS 

• WINDOWS UTILITY SOFTWARE PROVIDED 

• XT AND AT INTERRUPT JUMPERS 

• OTHER PRODUCTS INCLUDING LAPTOP 
ADD-ONS 

• DELIVERY FROM STOCK 

• MADE IN USA 

• EXCELLENT TECHNICAL SUPPORT 


SEdLEVEL ™™ STEMSINC 

LIBERTY, SC 29657 

( 803 ) 843-4343 
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If you can direct me to even one 
prospective publisher for this kind of 
material you'll have made my day. 
Please find enclosed a SASE for your 
convenience in answering. Thanks. 

Sincerely, 

Homer B. Tilton 

I was going to take a crack at 
naming two magazines for hackers, 
but I figured out I couldn't define that 
word. In the community of program¬ 
mers I started out in, the word referred 
to anyone whose life revolved around 
computers, people who would (and 
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FLOATING POINT 
ARRAY PROCESSOR 

* Operates on Arrays & Matrices; 
Integer, Real, & Complex Structures. 

* Process math-intensive algorithms 
100 times faster than the 80387. 

* 598 mathematic & scientific functions 
on-board in EPROM, callable from C. 

* Private high speed STATIC memory 
(0.25 to 4.25 megabytes) on board. 

* 3 megabytes/sec to/from ISA host. 

* Direct hardware link to video & A/Ds. 

* 1000 page reference manual. 

* $2495.00 complete with software. 

* Call for function list and benchmarks. 

Eighteen Eight Laboratories 

1 -800-888-1119 FAX 702-294-2611 
1247 Tamarisk Lane 
Boulder City, NV 89005 
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often did) keep writing programs 
whether anyone was paying them or 
not. These days, people use the term 
to mean a wide variety of things, often 
derogatory. 

I am submitting the program you 
sent us to Leor (who is not the least 
bit prejudiced against DOS, Basic, or 
batch files) as a TECH Tip. You are 
right, though, there is not a huge 
market for this exact genre of code. 
We do try to judge each piece on its 
own merit, though, and one 
programmer's hack is sometimes 
another programmer’s elegant solu¬ 
tion. As a sometimes-rejected author, I 


SDLC, HDLC 
And X.25 Support 

Use Sangoma hardware and software 
to provide fast, cost effective, robust 
and easy to use SDLC, HDLC and X.25 
links from MS-DOS, UNIX, Concurrent 
DOS etc. 

All real time communication functions 
are performed by intelligent coproces¬ 
sor card. Line speeds up to 160 kbps 
are supported. Powerful debugging, 
line statistics and trace facilities are 
included. 

Full function SNA emulation packages 
also available. 

Sill1{£Oltl<i Technologies Inc. 

n (416) 474-1990 (800) 388-2475 


•C' and C++' DOCUMENTATION TOOLS 


! AUTOMATED DOCUMENTATION ! 

• C-CALL ($59) Creates a graphic-tree of 
the caller/called functions, and creates 
a files-vs-functions table of contents. 

• C-CMT ($59) Creates/inserts/updates 
comment-blocks for each function, listing 
the functions and identifiers used by it. 

• C-METRIC ($49) new! Calculates the path 
'cyclomatic' complexity of functions, counts 

lines of Comments, Code, 'C' statements. 

• C-LIST ($49) Lists and action-diagrams, 
or reformats source into standard formats. 

• C-REF ($49) Creates cross-reference of 
local/global/define/parameter identifiers. 

• SPECIAL OFFER ($189) All 5 programs, 
fully integrated as C-DOC DOS program, 
plus free OS/2 protected-mode program. 

• 30-DAY Money-back guarantee CALL NOW 

SOFTWARE BLACKSMITHS INC. 

6064 St Ives Way, Mississauga 

0^^anad^^j^M^(^6W58-4466 
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have come to the conclusion that per- 
serverance is rewarded a lot more 
often for technical writers than for 
novelists or poets! 

Also, if I might make some inferences 
about your personal definition of 
“hacker," take a look at Bill Gates' (no 
relation) Midnight Engineering. I don't 
know that he buys this sort of article, 
but you might enjoy the atmosphere of 
his magazine. It often features people 
who are not afraid of tackling 
problems they were not professionally 
trained to solve. Thanks for giving us a 
shot at buying this article, -rib 


32-bit Protected Mode 
386 C Graphics Library 

Intel 386/486 C Code Builder 
MetaWare, MicroWay, SVS, 
Watcom & Zortech with 
Phar Lap 3861 ASM 

Mixed Raster/Vector, 
Scalable, Rotatable Font, 
VGA, SVGA, 8514/A, VESA, 
Hercules Graphics Station 
through 1024x768x256 (8-bit), 
640x480x32k (16-bit), 
512x480x16.7m (32-bit), 
WYSIWYG HP-GL/PostScript 
$200 NO ROYALTIES 
FULL SOURCE CODE 
Gary R. Olhoeft 
P.O. Box 10870 Edgemont 
Golden, CO 80401-0620 
303-877-3697 CIS 76665,2021 
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NETWORK 

CONTROL 

LIBRARIES 

NETBIOS ROUTINES allows ac¬ 
cess to low-level network func¬ 
tions. Name, session, and 
datagram routines. Wait and no¬ 
wait options. $99 

NETBIOS DLL for Windows $199 

NETWORK MASTER provides 
access to Netware internal func¬ 
tions. Complete network control 
from your compiled programs! $99 

Starlight Software 

P.O. Box 1090 
Wheeling, IL 60090 

(708) 394-0622 _ 
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MS dos System 
Programming 

2nd Edition 


Edited by Robert Ward 
NOW- You can get the informa¬ 
tion most programmers don’t 
even know about. 

PLUS —Gain access to a critical 
bibliography that will become an 
indispensible resource to you. 

HIGHLY TECHNICAL 
HIGHLY FOCUSED 


MS-dos 

system programming 


Every entry is written by 
working programmers for 
working programmers. In¬ 
cluded are compiler- 
specific insights that will 
save you hours of work. 
Find out how to exploit spe¬ 
cial Turbo C features to 
simplify device drivers. Plus 
a bibliography designed to 
help the serious program¬ 
mer develop a personal 
library of MS-dos literature. 


Released July 1991, 240 pp. ISBN 0-923667-20-2 


edited by 
ROBERT WARD 


Nitty Gritty Coverage on 
These How-to Topics 


DIRECTLY Windows/DOS 

FROM 


Critical Error Handlin 
Customizing the DO 
Boot Strap 
Interrupt-Driven I/O 
Manipulating 
Environmental Variables 
Event Timing 
Writing TSRs 
Controlling the Disk 
Hardware 
Writing Device ^1 

Drivers __ I L^/ 

ONLY 

$24® 


□ DEVELOPER'S JOURNAL 



913 - 841-1631 

FAX: 913-841-2624 



ST@P! 


Over 18,000 
Windows developers 
are reading this ad. 
Shouldn’t your product 
be here? 


Call us at 913-841-1631 
to receive a free media kit. 
You’ll be glad you did. 

Windows/DOS 

□ DEVELOPER'S JOURNAL 


CALL 

913 - 841-1631 

TODAY! 
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FREE 

Product 

Information 

Use this postage paid 
card to stay up to date 
on products 
that affect 
your productivity. 

Just fill out the card at 
the right and 
drop it in the mail. 



Windows/POS 

□ DEVELOPER'S JOURNAL 


Please help us serve you by 
answering the following: 

1) I program: 

□ for a living 

□ asahobby 

□ as a manager 

2) I program in: 

□ MS-DOS 

□ Macintosh 

□ Xenix/UNIX 

3) I program most frequently in: 


1601 W. 23rd St., Ste. 200 
P.O. Box 3127 
Lawrence, KS 66046-9943 
(913) 841-1631 FAX: (913) 841-2624 

REQUEST READER SERVICE NUMBERS: 


Use with the February 1992 issue only. 


Windows 

Assembly 

Pascal 

BASIC 

C 

Other 


NAME 

COMPANY 


ADDRESS 


CITY/STATE/ZIP 


□ Please send me subscription information, ph^ne 


3.2 


NO POSTAGE 
NECESSARY 
IF MAILED 
IN THE 

UNITED STATES 


BUSINESS REPLY MAIL 

FIRST CLASS PERMIT NO. 682 LAWRENCE, KS 

Postage will be paid by addressee 

Windows/POS 

□ DEVELOPER'S JOURNAL 

1601 W. 23rd St., Suite 200 
P.O. Box 3127 
Lawrence, KS 66046-9943 
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1601 W. 23rd. St., Ste. 200 
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Lawrence, KS 66046-9943 




Windows/POS 

□ DEVELOPER'S JOURNAL 

□ YES! Send me 12 issues of Windows/DOS Developer’s Journal for only $29! 

□ 2 years (24 issues) for $54 □ 3 years (36 issues) for $77 

□ Bill Me □ Visa □ MasterCard 

Number_ Exp. _ 

Signature_ 


Name 


Company 


Address 

City 

State 


Zip 


CountryIProvince/Mailcode 


3.2 


Please allow up to six weeks for delivery of first issue. Orders outside the US must be prepaid in US funds. CANADA/MEXICO 
subscriptions are: 1 year - $38; 2 years-$63; 3 years - $86. Overseas subscriptions are: 1 year - $48; 2 years-$88; 3 years-$126. 


FREE 

Product 

Information 

Use this postage paid 
card to stay up to date 
on products 
that affect 
your productivity. 

Just fill out the card at 
the right and 
drop it in the mail. 
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INSTALL 3.1 GIVES 
YOUR SOFTWARE 
PRODUCT A 
PROFESSIONAL 
INTRODUCTION. 


Installation procedures that rely on 
batch files and DOS commands not 
only look amateurish but also have 
limited error handling capabilities. 
Today's users expect quality and 
ease-of-use from their software 
beginning the moment they open 
the package. A smooth, professional 
installation makes an important first 
impression. 


NEW FEATURES 

Over 50 new/enhanced keywords 
Now licensed once, like a compiler 
Supports products of unlimited size 
INSTALL.EXE is still less than 80K 
Displays no copyright banner 
Supports Borland C++ 3.0 

Microsoft Windows Version 
coming soon! 


PROVEN 

RELIABILITY 


INSTALL 3.1 has been used for over 
four years by some of the biggest 
(and smallest!) names in the industry, 
in the U.S. and abroad, to install 
millions of copies of their programs. 
Add your name to that list today. 


INSTALL PRO 

* Builds Distribution Disk 

Sets Automatically 

* Full Screen Interface 

* Creates Script Files 
and DISK.ID Files 

* FHigh Performance 
Data Compression 

* Slashes Work Time 
Up to 75% 

* Splits & Compresses 
Files Of Any Size 

* Can Tag A File, Directory, 
Or Directory Tree With 
One Keystroke 

* Can Automatically Format 
360K, 720K, 1.2M, 

and 1.44M Disks 

* Fully Compatible With 
Install 2.0 & Later 


Knowledge 

Dynamics 

Corporation 

P.O. Box 1558 

Canyon Lake, Texas 78130-1558 

CALL OR FAX BY 10 am 
(CST) AND RECEIVE 
INSTALL 3.1 TOMORROW 
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EVERYTHING 
YOU NEED 

INSTALL 3.1 is customized for your 
product with an ASCII text file called 
a "script file". INSTALL 3.1 comes with 
many sample script files that you can 
modify and use immediately. No 
programming is necessary to create 
most installations. Flowever, C source 
code is included for your 
convenience and technical support 
is free. 

FAST AND SIMPLE 

Use INSTALL 3.1 to create an elegant 
installation procedure that will 
increase users' confidence in your 
product. INSTALL 3.1 takes 
advantage of all available RAM for 
lightning-fast file transfers. All your 
documentation has to tell users is 
TYPE "A:INSTALL". 

30 DAY MONEY- 
BACK GUARANTEE 

Free technical support. No 
royalties. MasterCard/VISA/ 
COD/POs welcome. 

$399.95 INSTALL 3.1 PRO 
$249.95 INSTALL 3.1 Standard 
$ 99.95 International Option 
$ 99.95 OS/2 Option 

SALES 

1/800-331-2783X195 

International 1/512-964-3994 
24 hour FAX 1/512-964-3958 
24 hour BBS 1/512-964-3929 
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Get Inside WINDOWS! 





Soft 



Microsoft 

Windows 

Vferskm 3jO Compatible Product 


Debug Windows at the systems level! 


Soft-ICE/W takes you inside Windows! Debug and explore with power 
and flexibility not found in any other Windows debugger! Soft-ICE/W 
allows you to debug at the systems or applications level or simply learn 
the inner workings of Windows. 

• Debug VxD's, drivers and interrupt routines at source level 

• Debug interactions between DOS T&SR's and Windows Apps 

• Debug programs in DOS boxes 

• Display valuable system information 

(from the total memory occupied by a Windows application, to the 
complex internal structures of Windows) 

Soft-ICE/W uses the 386/486 architecture to provide break point 
capabilities that normally require external hardware. Nu-Mega, which 
pioneered this technology with the introduction of its award winning 
Soft/ICE for DOS, now gives Windows programmers the same debug¬ 
ging power... and still at a software price. 

Own the debugger that combines the best "view" of Windows internals 
with the most powerful break points of any software debugger. 

Soft-ICE/W. . . Only $ 386 

CodeView for Windows users: see what you're debugging without flash. 
CV/1 version 2.0 runs CodeView in a graphics window while viewing your 
application screen. Runs on anv display that supports Windows. 

CV/l . . . Only $129 

Buy any Nu-Mega product and get CV/1 for only $69. 


- WHAT THE EXPERTS ARE SAYING - 

"Soft-ICE for Windows is great! It helped me 
find, in fifteen minutes, a killer bug in a 
Windows virtual device driver that had 
eluded two people for several months. I 
cant see doing Windows development of 
any kind -- whether writing Windows 
applications, device drivers, or even DOS 
programs that have to run under Windows - 
without it. In addition to being great for 
finding bugs, Soft-ICE for Windows has been 
essential for my work on a forthcoming book: 
on Undocumented Windows . Soft-ICE for 
Windows goes anywhere and does 
everything, so it's essential for anyone who 
wants to poke around inside Windows 
Enhanced mode. DOS programmers will find 
it a perfect way to learn how the Windows 
DOS extender and DPMI server work, and 
how Windows interacts with DOS. Windows 
Enhanced mode is the hacker's paradise of 
the 90s, and Soft-ICE for Windows is the tool 
that every serious Windows or DOS hacker 
will need. Nu-Mega has done a brilliant 
job!" 

Andrew Schulman 

Software Engineer. Phar Lap Software 

Editor. Undocumented DOS 

Coauthor. Undocumented Windows <forthcoming ) 


Call (603) 889-2386 
fax (603) 889-1135 

p Nu-Mega 

RISK = NULL 

30 DAY 

MONEY-BACK GUARANTEE 

P.O. Box 7780 

Nashua, NH 03060-7780 U.S.A. 

TECHNOLOGIES INC 



MICROSOFT WINDOWS IS A REGISTERED TRADEMARK OF MICROSOFT CORP. Soft-ICE/W AND CV/1 ARE TRADEMARKS OF NU-MEGA TECHNOLOGIES, INC. 
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